On Wed, May 1, 2013 at 12:44 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
After being contacted by the emacs developers and others who are stuck with
Bazaar, which at this point seems to be utterly abandoned, I realized the
current
On Tue, Apr 30, 2013 at 10:28:21AM -0400, Marc Branchaud wrote:
On 13-04-29 05:15 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
Thanks.
When using git subtree push to split out a subtree and push it to a
remote repository, we do not detect if the split command fails which
causes the LHS of the refspec to be empty, deleting the remote branch.
Fix this by pulling the result of the split command into a variable so
that we can die if
IB In my repo the placeholders change too often (in 1/4 commits). I'm
IB thinking of using:
IB 'git config --unset svn-remote.$repo_id.added-placeholder path_regex'
IB instead of full rewrite.
I need your help. There are still problems:
$ grep define MAX_MATCHES ~/builds/git/git-git/config.c
Duy Nguyen pclo...@gmail.com writes:
On Wed, May 1, 2013 at 12:15 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Duy Nguyen wrote:
We could put still ref aliases
into the same ref namespace, with lower precedence that actual refs,
so no new syntax required.
Actually, ref-alises are
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 as 'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a
On Wed, May 1, 2013 at 5:51 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 patch allows '@' to be the same as
On 1 May 2013 11:12, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, May 1, 2013 at 5:51 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
This series attempts to reduce the cost of check_everything_connected
on the clone case where index-pack is run. For example, cloning
file://../linux-2.6.git:
before after
real4m23.664s3m47.280s
user4m55.613s4m39.530s
sys 0m14.805s0m17.728s
The first
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 pclo...@gmail.com
---
builtin/clone.c | 4
1 file changed, 4 insertions(+)
diff --git
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.
A new environment variable GIT_SHALLOW_FILE is used to
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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..1fd56d9 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -747,8 +747,7 @@
--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_connected() except that:
- it does not follow DAG in order
- it can detect incomplete object islands
- it seems to be faster
This replaces check_everything_connected() with --not-so-strict, which
accomplishes the same thing and is generally cheaper when index-pack
or unpack-objects are used. All other cases fall back to
check_everything_connected.
This could help reduce the impact of check_everything_connected() on
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
Give better advice when trying to merge a branch that doesn't exist. If
the branch exists in any remotes, display a list of suggestions.
Example:
$ git merge foo
fatal: foo - not something we can merge
Did you mean this?
bar/foo
Signed-off-by: Vikrant Varma
The previous patch added help_unknown_ref to print a more helpful error
message when trying to merge a branch that doesn't exist, by printing a
list of remote branches the user might have meant. Use it.
Signed-off-by: Vikrant Varma vikrant.varm...@gmail.com
---
builtin/merge.c | 4 ++--
1 file
Vikrant Varma wrote:
Give better advice when trying to merge a branch that doesn't exist. If
the branch exists in any remotes, display a list of suggestions.
Interesting. Thanks for working on this.
You say advice, but you're not invoking advise() or guarding the
advice with an advice.* --
On 13-05-01 04:24 AM, Lukas Fleischer wrote:
On Tue, Apr 30, 2013 at 10:28:21AM -0400, Marc Branchaud wrote:
On 13-04-29 05:15 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
This started out as an attempt to make the backward compatibility notes
more parsable, but then
On 13-05-01 06:31 AM, Thomas Adam wrote:
On 1 May 2013 11:12, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, May 1, 2013 at 5:51 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
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.
* Edit (default): Enter edit mode.
I like this much
Hi,
Felipe's approach to solving the problem is a recursive reinterpret()
that relies on parsing the sequence @[^{]. Seems like quite a
contrived hack, and I think we can do much better than this.
Here, I present my approach to solving the problem. It interprets @
just like a ref in
The @-parsing loop unnecessarily checks for the sequence @{ from
len - 2 unnecessarily. We can safely check from len - 4: write out a
comment justifying this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 18 +-
1 file changed, 17 insertions(+), 1
Presently, the logic for @-parsing is horribly convoluted. Prove that
it is very straightforward by laying out the three cases (@{N},
@{u[upstream], and @{-N}) and explaining how each case should be
handled in comments. All tests pass, and no functional changes have
been introduced.
Currently, branch_get() either accepts either a branch name, empty
string, or the magic four-letter word HEAD. Make it additionally
handle symbolic refs that point to a branch.
Update sha1_name.c:interpret_branch_name() to look for @{, not '@'
(since '@' is a valid symbolic ref).
These two
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
Felipe Contreras felipe.contre...@gmail.com writes:
So let's go ahead and apply these directly on top of 'master', once
we hear from Emacs folks and they are happy with it. I'll queue it
on 'pu' so that I do not have to go back to the list archive when it
happens.
I already heard that
Ilya Basin basini...@gmail.com writes:
IB In my repo the placeholders change too often (in 1/4 commits). I'm
IB thinking of using:
IB 'git config --unset svn-remote.$repo_id.added-placeholder path_regex'
IB instead of full rewrite.
I need your help. There are still problems:
$ grep
Marc Branchaud mbranch...@xiplink.com writes:
On 13-05-01 06:31 AM, Thomas Adam wrote:
On 1 May 2013 11:12, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
So HEAD@{0}~0^0 is too much to type, but we can remove
I maintain a local wiki at my $dayjob which contains a page dedicated
to Git which, among other things, liks to various useful bits of
information on the internets.
Recently I discovered that a number of useful articles which sort of
accompanied the Pro Git book are now inaccessible (404),
Marc Branchaud marcn...@xiplink.com writes:
A third suggestion:
git bundle erroneously bailed out when parsing a valid bundle
containing a prerequisite commit without a commit message.
I like that best.
Concurred. Thanks for your help, all.
--
To unsubscribe from this list: send
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
The @-parsing loop unnecessarily checks for the sequence @{ from
len - 2 unnecessarily. We can safely check from len - 4: write out a
comment justifying this.
Signed-off-by: Ramkumar Ramachandra
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Currently, branch_get() either accepts either a branch name, empty
string, or the magic four-letter word HEAD. Make it additionally
handle symbolic refs that point to a branch.
Update
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
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,
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: cannot fork()
Vikrant Varma wrote:
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
On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
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}'?
On Wed, May 1, 2013 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
So let's go ahead and apply these directly on top of 'master', once
we hear from Emacs folks and they are happy with it. I'll queue it
on 'pu' so that I do not have to
Vikrant Varma vikrant.varm...@gmail.com writes:
Give better advice when trying to merge a branch that doesn't exist. If
the branch exists in any remotes, display a list of suggestions.
Example:
$ git merge foo
fatal: foo - not something we can merge
Did you mean this?
Vikrant Varma vikrant.varm...@gmail.com writes:
The previous patch added help_unknown_ref to print a more helpful error
message when trying to merge a branch that doesn't exist, by printing a
list of remote branches the user might have meant. Use it.
Signed-off-by: Vikrant Varma
Felipe Contreras wrote:
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
+ refs_found = dwim_log(str, len, sha1, real_ref);
+
+ if (!refs_found str[2] == '-') {
You are changing the behavior, there's no need for
On Wed, May 01, 2013 at 09:28:39PM +0400, Konstantin Khomoutov wrote:
I maintain a local wiki at my $dayjob which contains a page dedicated
to Git which, among other things, liks to various useful bits of
information on the internets.
Recently I discovered that a number of useful articles
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 1, 2013 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
So let's go ahead and apply these directly on top of 'master', once
we hear from Emacs folks and they are happy
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, the SHA-1 takes
precedence and refs with the same name are ignored.
That's
Felipe Contreras wrote:
But why? I'm not familiar with branch_get, but my intuition tells me
you are changing the behavior, and now branch_get() is doing something
it wasn't intended to do. And for what?
Why is there a commit message? I've explained what the behavior change is.
Your
Felipe Contreras wrote:
I think this comment is overkill.
That's not for one line. It's for the whole logic following it: there
are things like (len-1) - (at+2) which are easy to visualize with this
picture. They're int, not char *.
--
To unsubscribe from this list: send the line unsubscribe
Ramkumar Ramachandra artag...@gmail.com writes:
To emphasize what we're testing in @{1}@{u}, document that @{0}@{0} is
also nonsense. This makes it clear that @{n} does not resolve to a
ref whose upstream we can determine with @{u}/ reflog we can dig with
@{0}.
Since HEAD is implicit in
Ramkumar Ramachandra wrote:
[1]: https://www.ohloh.net/p/git/factoids#FactoidCommentsLow
Since this has been coming up from time to time:
I have nothing against including helpful comments where appropriate.
But one aspect which that factoid misses is that git has some very
detailed, very dense
On Wed, 1 May 2013 14:38:02 -0400
Jeff King p...@peff.net wrote:
[...]
Recently I discovered that a number of useful articles which sort of
accompanied the Pro Git book are now inaccessible (404), namely:
Smart HTTP Transport [1], Reset Demystified [2], Note to
Self [3] and Git Loves the
Felipe Contreras wrote:
Does the user really cares if it's a pseudo-ref or not? Also, what
does it mean that refers to HEAD?
It's not about whether the user cares or not; it's about saying it in
a way that doesn't make it less precise. I'm saying @ is like a
symbolic-ref .git/@ ref referring
On Wed, May 1, 2013 at 1:36 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
+ refs_found = dwim_log(str, len, sha1, real_ref);
+
+ if
On Wed, May 1, 2013 at 1:44 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
But why? I'm not familiar with branch_get, but my intuition tells me
you are changing the behavior, and now branch_get() is doing something
it wasn't intended to do. And for what?
Why is
On Wed, May 1, 2013 at 2:00 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
Does the user really cares if it's a pseudo-ref or not? Also, what
does it mean that refers to HEAD?
It's not about whether the user cares or not; it's about saying it in
a way that doesn't
Felipe Contreras wrote:
On Wed, May 1, 2013 at 1:36 PM, Ramkumar Ramachandra artag...@gmail.com
wrote:
This is not a reorganization patch. I said simplify: not refactor.
I'd say you should start with a reorganization, and then a simplification.
You don't think I already tried that? There
Felipe Contreras wrote:
As I said, the @@{u} thing can be fixed through other ways.
It's not just @@{u}. I can have lots of custom symbolic refs working
properly; I might choose D for my deleted-reflogs, M for master and so
on.
$ git log M..
The point is that my solution solves the
Felipe Contreras wrote:
If I put my user shoes, I don't care how @ is implemented, I just care
that it's a shortcut for HEAD, that's what it means to me, the common
user.
Okay, we'll change this.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
JCH ...and you want to perform a merge on the
JCH Git side of that branch with another Git branch that does have real
JCH contents in that directory, you would want the result to say This
JCH directory no longer is just for a placeholder, but you cannot say
JCH that globally by updating the config
On 01-05-2013 17:53, Ramkumar Ramachandra wrote:
Vikrant Varma wrote:
Give better advice when trying to merge a branch that doesn't exist. If
the branch exists in any remotes, display a list of suggestions.
Interesting. Thanks for working on this.
You say advice, but you're not invoking
Jonathan Nieder wrote:
Since this has been coming up from time to time:
[...]
Thanks, I didn't know about 'git gui blame'.
I think both comments and commit messages have their uses. One cannot
do the job of the other.
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Am 01.05.2013 21:55, schrieb Vikrant Varma:
On 01-05-2013 17:53, Ramkumar Ramachandra wrote:
Vikrant Varma wrote:
+void help_unknown_ref(const char* ref) {
+int i;
+struct similar_ref_cb ref_cb;
+ref_cb.similar_refs = (struct string_list)STRING_LIST_INIT_NODUP;
Why
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. Make fetch-pack save shallow file to
disk before invoking index-pack.
A
Vikrant Varma wrote:
I agree with Matthieu, the people who don't want to see this advice never
will, because they won't make that mistake. Maybe advice is the wrong word,
corrections might be more appropriate.
Makes sense.
Perhaps it would make sense to hook into help.autocorrect. I would
The lookup_object function is backed by a hash table of all
objects we have seen in the program. We manage collisions
with a linear walk over the colliding entries, checking each
with hashcmp(). The main cost of lookup is in these
hashcmp() calls; finding our item in the first slot is
cheaper than
Paul Walmsley pjwh...@gmail.com wrote:
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
On Wed, May 1, 2013 at 2:50 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
As I said, the @@{u} thing can be fixed through other ways.
It's not just @@{u}. I can have lots of custom symbolic refs working
properly; I might choose D for my deleted-reflogs, M for
On Thu, Apr 25, 2013 at 08:04:01PM +0200, Thomas Rast wrote:
And probing lookups happen a lot: some simple instrumentation shows
that 'git rev-list --all --objects' on my git.git,
* 19.4M objects are accessed in lookup_object and grow_object_hash
combined, while
* the linear probing
Junio C Hamano wrote:
Just making sure. HEAD@{$n} and @{$n} for non-negative $n mean
totally different things. @{0} and HEAD@{0} are almost always the
same, and @{1} and HEAD@{1} may often happen to be the same, but as
a blanket statement, I find Since HEAD is implicit in @{} very
On Thu, May 02, 2013 at 02:34:01AM +0530, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
Just making sure. HEAD@{$n} and @{$n} for non-negative $n mean
totally different things. @{0} and HEAD@{0} are almost always the
same, and @{1} and HEAD@{1} may often happen to be the same, but as
Ilya Basin basini...@gmail.com wrote:
JCH comment line # added by git-svn only to keep the directory and
JCH consider a directory that has nothing but .gitignore that consists
JCH of only that exact comment line an added placeholder directory to
JCH work it around.
Sounds good, but it's not I
On 02-05-2013 02:02, Ramkumar Ramachandra wrote:
ref_cb.similar_refs has already been defined. The compiler won't let me
assign to it unless I cast first. However, I think compound literals are a
C99/gcc feature. Is this better?
struct similar_ref_cb ref_cb = {ref,
Eric Wong normalper...@yhbt.net writes:
Ilya Basin basini...@gmail.com wrote:
JCH comment line # added by git-svn only to keep the directory and
JCH consider a directory that has nothing but .gitignore that consists
JCH of only that exact comment line an added placeholder directory to
JCH
Jeff King p...@peff.net writes:
We could instead bump X into the `i` slot, and then shift
the whole contiguous chain down by one, resulting in:
index | i-1 | i | i+1 | i+2 |
---
entry ... | A | X | B | C | ...
Jeff King wrote:
The difference is that HEAD@{} refers to HEAD's reflog, but @{} refers
to the reflog of the branch pointed to by HEAD.
Ah, I missed this. Thanks for the testcase. My patch changes this
behavior, and I'm looking into the problem.
--
To unsubscribe from this list: send the line
Ramkumar Ramachandra wrote:
+ if (!len)
+ /* In the @{N} case where there's nothing
+* before the @.
+*/
+ refs_found = dwim_log(HEAD, 4, sha1, real_ref);
Minor mistake here: it should
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
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',
Vikrant Varma vikrant.varm...@gmail.com writes:
On 02-05-2013 02:02, Ramkumar Ramachandra wrote:
ref_cb.similar_refs has already been defined. The compiler won't let me
assign to it unless I cast first. However, I think compound literals are a
C99/gcc feature. Is this better?
On Wed, May 1, 2013 at 2:40 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
On Wed, May 1, 2013 at 1:36 PM, Ramkumar Ramachandra artag...@gmail.com
wrote:
This is not a reorganization patch. I said simplify: not refactor.
I'd say you should start with a
On Wed, May 1, 2013 at 3:57 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
If you are arguing in favor of arbitrary symbolic refs plus @{u} to
work, a patch that allows that, and nothing else, should make sense.
Such patch would trigger further discussion, for
On 02-05-2013 00:05, Junio C Hamano wrote:
If you step back a bit, you would notice two things.
(1) Saying 'foo' when the user means 'origin/foo' is hardly the
only (or even the most common) kind of mistake that the code
you need to add to 'git merge' would encounter and could
Felipe Contreras wrote:
On Wed, May 1, 2013 at 2:40 PM, Ramkumar Ramachandra artag...@gmail.com
wrote:
You don't think I already tried that? There is no way to sensibly
reorganize the old logic sensibly, in a way that doesn't break
anything.
See, I tried to split your patch into logical
On Wed, May 1, 2013 at 5:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
So HEAD@{0}~0^0 is too much to type, but we
On Wed, May 1, 2013 at 5:26 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
On Wed, May 1, 2013 at 2:40 PM, Ramkumar Ramachandra artag...@gmail.com
wrote:
There's no need to associate one comment with one line of code.
People can see clearly see the failure case
Jeff King p...@peff.net writes:
On Thu, May 02, 2013 at 02:34:01AM +0530, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
Just making sure. HEAD@{$n} and @{$n} for non-negative $n mean
totally different things. @{0} and HEAD@{0} are almost always the
same, and @{1} and HEAD@{1} may
Junio C Hamano gits...@pobox.com writes:
The thing is, HEAD@{0}~0^0 nor HEAD@{u}~0^0 is not a valid
explanation why it is @, either.
But that does _not_ mean @ is a good choice. Nor the explanation
Arrgh. It does not mean '@' is a BAD choice . '@' _is_ good.
But the point is that the
Felipe Contreras felipe.contre...@gmail.com writes:
Exactly, because ref@something is used for operations on a ref. If
'ref' is missing, it only makes sense to use HEAD (or something like
that), and if 'something' is missing, it only makes sense to make it a
no-op, but since we don't want to
On 01-05-2013 23:57, Jonathan Nieder wrote:
- It would be nice to add a test under t/
Thanks, I'll do that.
- Since the first patch isn't useful without or logically separate
from the second, this would probably be easier to read as a single
patch.
They are logically
Vikrant Varma vikrant.varm...@gmail.com writes:
On 02-05-2013 00:05, Junio C Hamano wrote:
If you step back a bit, you would notice two things.
(1) Saying 'foo' when the user means 'origin/foo' is hardly the
only (or even the most common) kind of mistake that the code
you need
On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Exactly, because ref@something is used for operations on a ref. If
'ref' is missing, it only makes sense to use HEAD (or something like
that), and if 'something' is
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 check_everything_connected() except that:
- it does not follow DAG in order
- it can detect
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
The @-parsing loop unnecessarily checks for the sequence @{ from
len - 2 unnecessarily. We can safely check from len - 4: write out a
comment justifying this.
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 Wed, May 01, 2013 at 04:49:47PM -0400, Jeff King wrote:
Another avenue I'd like to explore is actually doing a tree-diff from
the last processed commit, since we should need to examine only the
changed entries. I suspect it won't be a big benefit, though, because
even though the tree diff
On Wed, May 1, 2013 at 7:49 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
On Wed, May 1, 2013 at 7:49 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
On Wed, May 1, 2013 at 1:53 PM, Junio C Hamano gits...@pobox.com wrote:
As you and Felipe seem to be aiming for the same Let's allow users
to say '@' when they mean HEAD, I'll let you two figure the best
approach out.
One productive way forward might be to come up with a common test
script
On Wed, May 1, 2013 at 6:14 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
It is just the strip this, strip that explanation, which is not
technically correct, does _not_ have to be our justification for
picking
On Tue, Apr 30, 2013 at 9:03 PM, Duy Nguyen pclo...@gmail.com wrote:
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
Junio C Hamano gits...@pobox.com wrote:
Eric Wong normalper...@yhbt.net writes:
Ilya Basin basini...@gmail.com wrote:
JCH comment line # added by git-svn only to keep the directory and
JCH consider a directory that has nothing but .gitignore that consists
JCH of only that exact comment
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.
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
99 matches
Mail list logo
