Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Felipe Contreras
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

Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Ramkumar Ramachandra
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

Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Felipe Contreras
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

Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Ramkumar Ramachandra
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

Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Ramkumar Ramachandra
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

Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Ramkumar Ramachandra
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

Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Felipe Contreras
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] == '-'

Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Jonathan Nieder
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

Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Ramkumar Ramachandra
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

Re: [PATCH 3/5] sha1_name.c: simplify @-parsing in get_sha1_basic()

2013-05-01 Thread Felipe Contreras
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