Am 5/1/2013 22:34, schrieb Jeff King:
struct object *lookup_object(const unsigned char *sha1)
{
- unsigned int i;
+ unsigned int i, first;
struct object *obj;
if (!obj_hash)
return NULL;
- i = hashtable_index(sha1);
+ first = i =
On Thu, May 02, 2013 at 08:44:07AM +0200, Johannes Sixt wrote:
Am 5/1/2013 22:34, schrieb Jeff King:
struct object *lookup_object(const unsigned char *sha1)
{
- unsigned int i;
+ unsigned int i, first;
struct object *obj;
if (!obj_hash)
return NULL;
Am 5/2/2013 8:46, schrieb Jeff King:
On Thu, May 02, 2013 at 08:44:07AM +0200, Johannes Sixt wrote:
Am 5/1/2013 22:34, schrieb Jeff King:
struct object *lookup_object(const unsigned char *sha1)
{
- unsigned int i;
+ unsigned int i, first;
struct object *obj;
if (!obj_hash)
Jeff King p...@peff.net writes:
It _might_ still be advantageous to do your patch on top, but I suspect
it will diminish the returns from your patch (since the point of it is
to probe less far down the chain on average).
No, mine makes it slower again. Apparently the increased size is no
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+test_expect_success 'rev-parse 20-hex ref' '
+ REF=`git rev-parse HEAD`
+ VAL=`echo| git commit-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904`
+ git update-ref refs/heads/$REF $VAL
+ test `git rev-parse $REF` = $VAL
+'
+
Felipe Contreras wrote:
[...]
Yes, I'm working on a re-roll.
Moreover, the symbolic-ref 'HEAD' is quite special, it's mentioned
everywhere in the documentation, and the code has special cases for
it. It's not reasonable to expect all relevant places to be updated
for this functionality, and
Felipe Contreras wrote:
@@ -447,6 +449,9 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
if (len str[len-1] == '}') {
for (at = len-2; at = 0; at--) {
if (str[at] == '@' str[at+1] == '{') {
+
On Thu, May 2, 2013 at 4:07 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
[...]
Yes, I'm working on a re-roll.
Moreover, the symbolic-ref 'HEAD' is quite special, it's mentioned
everywhere in the documentation, and the code has special cases for
it. It's not
On Thu, May 2, 2013 at 6:35 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
On Thu, May 2, 2013 at 3:27 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
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.
On Thu, May 2, 2013 at 1:43 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Nguyễn Thái Ngọc Duy wrote:
git rev-parse 1234 will
resolve refs/heads/1234 if exists even if there is an unambiguous
SHA-1 starting with 1234. However if it's full SHA-1,
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 way, i'll go with it.
--
To unsubscribe from this list: send
On Thu, May 2, 2013 at 7:49 AM, Felipe Contreras
felipe.contre...@gmail.com 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
On Thu, May 2, 2013 at 12:15 PM, shawn wilson ag4ve...@gmail.com 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
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?
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
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
Signed-off-by: Jiang Xin worldhello@gmail.com
---
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
+++
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
From: Felipe Contreras felipe.contre...@gmail.com
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
From: Felipe Contreras felipe.contre...@gmail.com
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
From: Felipe Contreras felipe.contre...@gmail.com
Instead of setting the configuration variables branch.name.merge and
branch.name.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
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 artag...@gmail.com
---
t/t1508-at-combinations.sh | 14 ++
1 file changed, 14 insertions(+)
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 artag...@gmail.com
---
t/t1508-at-combinations.sh | 13
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
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
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
Add more tests exercising documented functionality.
It is worth nothing that HEAD@{-n} is senseless because @{-n}
cannot be used with anything other than HEAD anyway.
[fc: contribute a couple of tests]
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t1508-at-combinations.sh | 8
2013/5/1 Matthieu Moy matthieu@grenoble-inp.fr:
Jiang Xin worldhello@gmail.com 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.
On Thu, May 2, 2013 at 9:39 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
Add more tests exercising documented functionality.
It is worth nothing that HEAD@{-n} is senseless because @{-n}
s/nothing/noting/
cannot be used with anything other than HEAD anyway.
[fc: contribute a couple
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
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 obj-id. The client may have truncated the history at
the commit by fetching shallowly from a different server, or the commit
may have been
Jiang Xin worldhello@gmail.com writes:
Signed-off-by: Jiang Xin worldhello@gmail.com
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).
--
Jiang Xin worldhello@gmail.com 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
Jeff King p...@peff.net 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
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 not
Johannes Sixt j.s...@viscovery.net 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,
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 is
--
On Thu, May 02, 2013 at 08:46:08AM -0700, Junio C Hamano wrote:
Johannes Sixt j.s...@viscovery.net 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
Duy Nguyen pclo...@gmail.com writes:
On Thu, May 2, 2013 at 6:35 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
On Thu, May 2, 2013 at 6:03 AM, Ramkumar Ramachandra artag...@gmail.com 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
Duy Nguyen pclo...@gmail.com writes:
On Wed, May 1, 2013 at 4:49 AM, Felipe Contreras
felipe.contre...@gmail.com 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
Michael Heemskerk mheemsk...@atlassian.com 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
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:
On Thu, May 2, 2013 at 8:39 AM, Ramkumar Ramachandra artag...@gmail.com 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
On Thu, May 2, 2013 at 11:56 AM, Ramkumar Ramachandra
artag...@gmail.com 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
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,
Junio C Hamano gits...@pobox.com writes:
Michael Heemskerk mheemsk...@atlassian.com 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
On Thu, May 2, 2013 at 12:02 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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 slowly,
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-combinations):
On Thu, May 2, 2013 at 8:39 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
From: Felipe Contreras felipe.contre...@gmail.com
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
On Thu, May 2, 2013 at 12:18 PM, Ramkumar Ramachandra
artag...@gmail.com 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
On Thu, May 2, 2013 at 8:39 AM, Ramkumar Ramachandra artag...@gmail.com 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 artag...@gmail.com
---
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 think you
On Thu, May 2, 2013 at 12:28 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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 showing that HEAD@{1}
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 directory
On Thu, May 2, 2013 at 12:30 PM, Ramkumar Ramachandra
artag...@gmail.com 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
And here
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 unsubscribe
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 is,
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,
On Thu, May 2, 2013 at 5:19 AM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, May 2, 2013 at 7:49 AM, Felipe Contreras
felipe.contre...@gmail.com 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
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
On Thu, May 2, 2013 at 12:48 PM, Felipe Contreras
felipe.contre...@gmail.com 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
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.
Even
-C takes a commit object, not a file.
Signed-off-by: Anders Granskogen Bjørnstad ander...@gmail.com
---
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
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
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.
On Wed, May 1, 2013 at 10:49 PM, Eric Wong normalper...@yhbt.net wrote:
Junio C Hamano gits...@pobox.com wrote:
Eric Wong normalper...@yhbt.net 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
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
On Thu, May 2, 2013 at 1:55 PM, Ramkumar Ramachandra artag...@gmail.com 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
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 followed by
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 the
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
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
From: Jonathan Nieder jrnie...@gmail.com
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
Anders Granskogen Bjørnstad ander...@gmail.com writes:
-C takes a commit object, not a file.
Signed-off-by: Anders Granskogen Bjørnstad ander...@gmail.com
---
Documentation/git-commit.txt |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
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)
On Thu, May 2, 2013 at 2:47 PM, Ramkumar Ramachandra artag...@gmail.com 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
Kevin Bracey ke...@bracey.fi 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.
Ilya Basin basini...@gmail.com 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:
Ilya Basin basini...@gmail.com 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 #
Ramsay Jones ram...@ramsay1.demon.co.uk 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
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 your
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
2013/5/2 Matthieu Moy matthieu@grenoble-inp.fr:
Jiang Xin worldhello@gmail.com writes:
Signed-off-by: Jiang Xin worldhello@gmail.com
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
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 enhanced by
On Fri, May 3, 2013 at 2:27 AM, Junio C Hamano gits...@pobox.com 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
2013/5/2 Matthieu Moy matthieu@grenoble-inp.fr:
Jiang Xin worldhello@gmail.com 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
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
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
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
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()
There's no point in calling get_sha1() if we know they are SHA-1s.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 2 +-
fast-import.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/fast-export.c
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
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 felipe.contre...@gmail.com
---
builtin/fast-export.c | 2 +-
1 file changed, 1 insertion(+), 1
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 felipe.contre...@gmail.com
---
fast-import.c | 9 +++--
EW Ilya Basin basini...@gmail.com 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 #
99 matches
Mail list logo
