Re: confusion over the new branch and merge config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday 2006 December 22 00:46, Junio C Hamano wrote:

> You can always say "git log refs/heads/next" even though you are
> allowed to say "git log next".  Maybe we should remove that
> shorthand to make it consistent?   I think not.

On a related subject - I'd like to remove all the "refs/" literals from git.  
All refs are always under "refs/", so prefixing everything with refs/ is just 
noise.

The place that makes it stand out that this is wrong is (I think) found in 
refs.c (excuse my abuse of syntax):

int for_each_ref(each_ref_fn fn, void *cb_data)
    return do_for_each_ref("refs/", fn, 0, cb_data);
int for_each_tag_ref(each_ref_fn fn, void *cb_data)
    return do_for_each_ref("refs/tags/", fn, 10, cb_data);
int for_each_branch_ref(each_ref_fn fn, void *cb_data)
    return do_for_each_ref("refs/heads/", fn, 11, cb_data);
int for_each_remote_ref(each_ref_fn fn, void *cb_data)
    return do_for_each_ref("refs/remotes/", fn, 13, cb_data);

What's significant is that it is only for_each_ref() that hands the prefix 
back.  The change I'd like to make is 
    return do_for_each_ref("refs/", fn, 5, cb_data);

Obviously, this will imply a lot of changes everywhere else; so I didn't want 
to dive into it without mentioning it here first.

Is this a sensible thing to want to do?  

As I'm talking about code cleanups, I'd also like to change all variables 
called "sha1" to "hash" (or similar).  The point being that the variables 
hold hashes not sha1's.

I don't say that the above are serious problems, I just like cleaning code :-)


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]