On 30 April 2013 21:38, Junio C Hamano wrote:
> John Tapsell writes:
>
>> On 30 April 2013 20:44, Junio C Hamano wrote:
>>> John Tapsell writes:
>>>
Is there no way to fix --cc to work even in the edge cases?
>>>
>>> Can you clarify what you mean by "fix" and "edge cases"?
>>
>> My underst
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 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 i
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/c
Duy Nguyen writes:
> On Wed, May 1, 2013 at 12:15 AM, Ramkumar Ramachandra
> 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 the right way to solv
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
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 'HEAD'.
>
> So now we can u
On 1 May 2013 11:12, Eric Sunshine wrote:
> On Wed, May 1, 2013 at 5:51 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 allo
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 thre
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
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 i
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..1fd56d9 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -747,8 +747,7 @@ static void sha1_
--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 than
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
pack
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
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
---
builtin/merge.c | 4 ++--
1 file changed, 2 insertions(+),
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.* -- t
Ramkumar Ramachandra writes:
> You say advice, but you're not invoking advise() or guarding the
> advice with an advice.* -- the advice is undoubtedly helpful, but not
> everyone wants to see it.
Quite franckly, I don't see why anybody would need to disable it.
advice.* is very nice to disable m
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 writes:
>>>
This started out as an attempt to make the backward compatibility notes
more parsable, but then I j
On 13-05-01 06:31 AM, Thomas Adam wrote:
> On 1 May 2013 11:12, Eric Sunshine wrote:
>> On Wed, May 1, 2013 at 5:51 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
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.
I like this much more than the prev
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 resolve_ref
To emphasize what we're testing in @{1}@{u}, document that @{0}@{0} is
also nonsense. This makes it clear that @{} does not resolve to a
ref whose upstream we can determine with @{u}/ reflog we can dig with
@{0}.
Since HEAD is implicit in @{}, check that HEAD@{} works fine for these
cases. It do
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
---
sha1_name.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --g
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.
Signed-off-b
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 c
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
Felipe Contreras 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 everything seems to b
Ilya Basin 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 "define
John Keeping writes:
> 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
Marc Branchaud writes:
> On 13-05-01 06:31 AM, Thomas Adam wrote:
>> On 1 May 2013 11:12, Eric Sunshine wrote:
>>> On Wed, May 1, 2013 at 5:51 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',
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), namel
Felipe Contreras 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}'?
>
> This patch allows '@' to be the same as 'HEAD'.
While the above reasoning is cute, it is mislead
Marc Branchaud 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 the line
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
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
> ---
> sha1_name.c | 18 ++
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
wrote:
> 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 tes
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
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 sha1_name.c:interpret_branch_name() to l
On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
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, resolve_ref_unsafe()
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
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 somethi
On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano wrote:
> Felipe Contreras 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}'?
>>
>> This patch allows '@' to be the s
On Wed, May 1, 2013 at 11:39 AM, Junio C Hamano wrote:
> Felipe Contreras 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
Vikrant Varma 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?
> bar/foo
Vikrant Varma 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
> ---
> builtin/merge.c | 4 +
Felipe Contreras wrote:
> On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
> 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 that in t
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 articl
Felipe Contreras writes:
> On Wed, May 1, 2013 at 11:39 AM, Junio C Hamano wrote:
>> Felipe Contreras 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 t
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.
Th
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 rati
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 writes:
> To emphasize what we're testing in @{1}@{u}, document that @{0}@{0} is
> also nonsense. This makes it clear that @{} does not resolve to a
> ref whose upstream we can determine with @{u}/ reflog we can dig with
> @{0}.
>
> Since HEAD is implicit in @{},...
Just ma
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 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 t
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 referri
On Wed, May 1, 2013 at 1:36 PM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>> On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
>> wrote:
>>> + refs_found = dwim_log(str, len, sha1, &real_ref);
>>> +
>>> + if (!refs_found && str[2] == '-'
On Wed, May 1, 2013 at 1:44 PM, Ramkumar Ramachandra 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 there a comm
On Wed, May 1, 2013 at 2:00 PM, Ramkumar Ramachandra 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 make it
Felipe Contreras wrote:
> On Wed, May 1, 2013 at 1:36 PM, Ramkumar Ramachandra
> 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 is no way t
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 proble
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 ma
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
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 advi
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 b
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
Nguyễn Thái Ngọc Duy 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 new environ
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 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 want a git-sv
On Wed, May 1, 2013 at 2:50 PM, Ramkumar Ramachandra 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 master and so
>
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 prob
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 example, if
> get_branch() is the right place to achieve that.
What kind of absurd
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
> mis
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,
Ilya Basin 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 who de
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, STRING_LIST_INIT_NODU
Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra (5):
> t1508 (at-combinations): more tests; document failures
> sha1_name.c: don't waste cycles in the @-parsing loop
> sha1_name.c: simplify @-parsing in get_sha1_basic()
> remote.c: teach branch_get() to treat symrefs other than HEAD
>
Eric Wong writes:
> Ilya Basin 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
Jeff King 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 lin
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
Felipe Contreras writes:
> On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano wrote:
>> Felipe Contreras 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}'?
>>>
>
Vikrant Varma 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?
>>>
>>> struct similar_
On Wed, May 1, 2013 at 2:40 PM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>> On Wed, May 1, 2013 at 1:36 PM, Ramkumar Ramachandra
>> wrote:
>>> This is not a reorganization patch. I said "simplify": not refactor.
>>
>> I'd say you should start with a reorganization, and then a simpl
On Wed, May 1, 2013 at 3:57 PM, Ramkumar Ramachandra 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 example, if
>> ge
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 help
Felipe Contreras wrote:
> On Wed, May 1, 2013 at 2:40 PM, Ramkumar Ramachandra
> 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 changes, s
On Wed, May 1, 2013 at 5:08 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano wrote:
>>> Felipe Contreras 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',
On Wed, May 1, 2013 at 5:26 PM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>> On Wed, May 1, 2013 at 2:40 PM, Ramkumar Ramachandra
>> wrote:
>>> There's no need to associate one comment with one line of code.
>>> People can see clearly see the failure case following it.
>>
>> Is that
Jeff King 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 of
Junio C Hamano 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 explanation
Felipe Contreras 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 forbid refs with names
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 separate,
Vikrant Varma 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 to add to 'git
On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano wrote:
> Felipe Contreras 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
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_connected() except that:
>
> - it does not follow DAG in order
> - it can detect incomplete o
Felipe Contreras writes:
> On Wed, May 1, 2013 at 11:20 AM, Ramkumar Ramachandra
> 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 Ramac
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'
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 di
On Wed, May 1, 2013 at 7:49 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} subs
1 - 100 of 108 matches
Mail list logo
