2005-08-04 13:15:49 +08:00
|
|
|
#include "cache.h"
|
2005-10-14 09:57:40 +08:00
|
|
|
#include "tag.h"
|
2005-08-04 13:15:49 +08:00
|
|
|
#include "commit.h"
|
2005-10-14 09:57:40 +08:00
|
|
|
#include "tree.h"
|
|
|
|
#include "blob.h"
|
2006-04-20 02:56:53 +08:00
|
|
|
#include "tree-walk.h"
|
2006-05-17 17:56:09 +08:00
|
|
|
#include "refs.h"
|
2009-09-10 23:25:57 +08:00
|
|
|
#include "remote.h"
|
2015-05-20 05:44:23 +08:00
|
|
|
#include "dir.h"
|
2016-09-26 20:00:33 +08:00
|
|
|
#include "sha1-array.h"
|
2005-08-04 13:15:49 +08:00
|
|
|
|
2010-12-13 11:01:15 +08:00
|
|
|
static int get_sha1_oneline(const char *, unsigned char *, struct commit_list *);
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
typedef int (*disambiguate_hint_fn)(const struct object_id *, void *);
|
2012-06-21 13:07:36 +08:00
|
|
|
|
|
|
|
struct disambiguate_state {
|
2016-09-26 20:00:04 +08:00
|
|
|
int len; /* length of prefix in hex chars */
|
2017-03-27 00:01:24 +08:00
|
|
|
char hex_pfx[GIT_MAX_HEXSZ + 1];
|
2017-03-27 00:01:33 +08:00
|
|
|
struct object_id bin_pfx;
|
2016-09-26 20:00:04 +08:00
|
|
|
|
2012-06-21 13:07:36 +08:00
|
|
|
disambiguate_hint_fn fn;
|
|
|
|
void *cb_data;
|
2017-03-27 00:01:33 +08:00
|
|
|
struct object_id candidate;
|
2012-06-21 13:07:36 +08:00
|
|
|
unsigned candidate_exists:1;
|
|
|
|
unsigned candidate_checked:1;
|
|
|
|
unsigned candidate_ok:1;
|
|
|
|
unsigned disambiguate_fn_used:1;
|
|
|
|
unsigned ambiguous:1;
|
2012-07-04 05:21:59 +08:00
|
|
|
unsigned always_call_fn:1;
|
2012-06-21 13:07:36 +08:00
|
|
|
};
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
static void update_candidates(struct disambiguate_state *ds, const struct object_id *current)
|
2012-06-21 13:07:36 +08:00
|
|
|
{
|
2012-07-04 05:21:59 +08:00
|
|
|
if (ds->always_call_fn) {
|
|
|
|
ds->ambiguous = ds->fn(current, ds->cb_data) ? 1 : 0;
|
|
|
|
return;
|
|
|
|
}
|
2012-06-21 13:07:36 +08:00
|
|
|
if (!ds->candidate_exists) {
|
|
|
|
/* this is the first candidate */
|
2017-03-27 00:01:34 +08:00
|
|
|
oidcpy(&ds->candidate, current);
|
2012-06-21 13:07:36 +08:00
|
|
|
ds->candidate_exists = 1;
|
|
|
|
return;
|
2017-03-27 00:01:34 +08:00
|
|
|
} else if (!oidcmp(&ds->candidate, current)) {
|
2012-06-21 13:07:36 +08:00
|
|
|
/* the same as what we already have seen */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ds->fn) {
|
|
|
|
/* cannot disambiguate between ds->candidate and current */
|
|
|
|
ds->ambiguous = 1;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ds->candidate_checked) {
|
2017-03-27 00:01:34 +08:00
|
|
|
ds->candidate_ok = ds->fn(&ds->candidate, ds->cb_data);
|
2012-06-21 13:07:36 +08:00
|
|
|
ds->disambiguate_fn_used = 1;
|
|
|
|
ds->candidate_checked = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ds->candidate_ok) {
|
2013-07-23 05:02:23 +08:00
|
|
|
/* discard the candidate; we know it does not satisfy fn */
|
2017-03-27 00:01:34 +08:00
|
|
|
oidcpy(&ds->candidate, current);
|
2012-06-21 13:07:36 +08:00
|
|
|
ds->candidate_checked = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if we reach this point, we know ds->candidate satisfies fn */
|
|
|
|
if (ds->fn(current, ds->cb_data)) {
|
|
|
|
/*
|
|
|
|
* if both current and candidate satisfy fn, we cannot
|
|
|
|
* disambiguate.
|
|
|
|
*/
|
|
|
|
ds->candidate_ok = 0;
|
|
|
|
ds->ambiguous = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* otherwise, current can be discarded and candidate is still good */
|
|
|
|
}
|
|
|
|
|
2016-09-26 20:00:04 +08:00
|
|
|
static void find_short_object_filename(struct disambiguate_state *ds)
|
2005-08-04 13:15:49 +08:00
|
|
|
{
|
2005-10-03 12:40:51 +08:00
|
|
|
struct alternate_object_database *alt;
|
2017-03-27 00:01:24 +08:00
|
|
|
char hex[GIT_MAX_HEXSZ];
|
2005-10-03 12:40:51 +08:00
|
|
|
static struct alternate_object_database *fakeent;
|
|
|
|
|
|
|
|
if (!fakeent) {
|
2012-06-19 02:41:03 +08:00
|
|
|
/*
|
|
|
|
* Create a "fake" alternate object database that
|
|
|
|
* points to our own object database, to make it
|
|
|
|
* easier to get a temporary working space in
|
|
|
|
* alt->name/alt->base while iterating over the
|
|
|
|
* object databases including our own.
|
|
|
|
*/
|
2016-10-04 04:35:31 +08:00
|
|
|
fakeent = alloc_alt_odb(get_object_directory());
|
2005-10-03 12:40:51 +08:00
|
|
|
}
|
|
|
|
fakeent->next = alt_odb_list;
|
2005-08-04 13:15:49 +08:00
|
|
|
|
2016-09-26 20:00:04 +08:00
|
|
|
xsnprintf(hex, sizeof(hex), "%.2s", ds->hex_pfx);
|
2012-06-21 13:07:36 +08:00
|
|
|
for (alt = fakeent; alt && !ds->ambiguous; alt = alt->next) {
|
2016-10-04 04:36:04 +08:00
|
|
|
struct strbuf *buf = alt_scratch_buf(alt);
|
2005-08-04 13:15:49 +08:00
|
|
|
struct dirent *de;
|
2005-10-03 12:40:51 +08:00
|
|
|
DIR *dir;
|
2016-10-04 04:35:51 +08:00
|
|
|
|
2016-10-18 04:25:19 +08:00
|
|
|
strbuf_addf(buf, "%.2s/", ds->hex_pfx);
|
2016-10-04 04:36:04 +08:00
|
|
|
dir = opendir(buf->buf);
|
2005-10-03 12:40:51 +08:00
|
|
|
if (!dir)
|
|
|
|
continue;
|
2012-06-21 13:07:36 +08:00
|
|
|
|
|
|
|
while (!ds->ambiguous && (de = readdir(dir)) != NULL) {
|
2017-03-27 00:01:34 +08:00
|
|
|
struct object_id oid;
|
2012-06-21 13:07:36 +08:00
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
if (strlen(de->d_name) != GIT_SHA1_HEXSZ - 2)
|
2005-08-04 13:15:49 +08:00
|
|
|
continue;
|
2016-09-26 20:00:04 +08:00
|
|
|
if (memcmp(de->d_name, ds->hex_pfx + 2, ds->len - 2))
|
2005-08-04 13:15:49 +08:00
|
|
|
continue;
|
2017-03-27 00:01:34 +08:00
|
|
|
memcpy(hex + 2, de->d_name, GIT_SHA1_HEXSZ - 2);
|
|
|
|
if (!get_oid_hex(hex, &oid))
|
|
|
|
update_candidates(ds, &oid);
|
2005-08-04 13:15:49 +08:00
|
|
|
}
|
|
|
|
closedir(dir);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int match_sha(unsigned len, const unsigned char *a, const unsigned char *b)
|
|
|
|
{
|
|
|
|
do {
|
|
|
|
if (*a != *b)
|
|
|
|
return 0;
|
|
|
|
a++;
|
|
|
|
b++;
|
|
|
|
len -= 2;
|
|
|
|
} while (len > 1);
|
|
|
|
if (len)
|
|
|
|
if ((*a ^ *b) & 0xf0)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-09-26 20:00:04 +08:00
|
|
|
static void unique_in_pack(struct packed_git *p,
|
2012-06-21 13:07:36 +08:00
|
|
|
struct disambiguate_state *ds)
|
2005-08-04 13:15:49 +08:00
|
|
|
{
|
2012-06-19 04:10:38 +08:00
|
|
|
uint32_t num, last, i, first = 0;
|
2017-03-27 00:01:34 +08:00
|
|
|
const struct object_id *current = NULL;
|
2012-06-19 04:10:38 +08:00
|
|
|
|
|
|
|
open_pack_index(p);
|
|
|
|
num = p->num_objects;
|
|
|
|
last = num;
|
|
|
|
while (first < last) {
|
|
|
|
uint32_t mid = (first + last) / 2;
|
|
|
|
const unsigned char *current;
|
|
|
|
int cmp;
|
|
|
|
|
|
|
|
current = nth_packed_object_sha1(p, mid);
|
2017-03-27 00:01:33 +08:00
|
|
|
cmp = hashcmp(ds->bin_pfx.hash, current);
|
2012-06-19 04:10:38 +08:00
|
|
|
if (!cmp) {
|
|
|
|
first = mid;
|
|
|
|
break;
|
2005-08-04 13:15:49 +08:00
|
|
|
}
|
2012-06-19 04:10:38 +08:00
|
|
|
if (cmp > 0) {
|
|
|
|
first = mid+1;
|
|
|
|
continue;
|
2005-08-04 13:15:49 +08:00
|
|
|
}
|
2012-06-19 04:10:38 +08:00
|
|
|
last = mid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* At this point, "first" is the location of the lowest object
|
2012-06-21 13:35:43 +08:00
|
|
|
* with an object name that could match "bin_pfx". See if we have
|
2012-06-19 04:10:38 +08:00
|
|
|
* 0, 1 or more objects that actually match(es).
|
|
|
|
*/
|
2012-06-21 13:07:36 +08:00
|
|
|
for (i = first; i < num && !ds->ambiguous; i++) {
|
2017-03-27 00:01:34 +08:00
|
|
|
struct object_id oid;
|
|
|
|
current = nth_packed_object_oid(&oid, p, i);
|
|
|
|
if (!match_sha(ds->len, ds->bin_pfx.hash, current->hash))
|
2012-06-19 04:10:38 +08:00
|
|
|
break;
|
2012-06-21 13:07:36 +08:00
|
|
|
update_candidates(ds, current);
|
2005-08-04 13:15:49 +08:00
|
|
|
}
|
2012-06-19 04:10:38 +08:00
|
|
|
}
|
|
|
|
|
2016-09-26 20:00:04 +08:00
|
|
|
static void find_short_packed_object(struct disambiguate_state *ds)
|
2005-08-04 13:15:49 +08:00
|
|
|
{
|
|
|
|
struct packed_git *p;
|
|
|
|
|
|
|
|
prepare_packed_git();
|
2012-06-21 13:07:36 +08:00
|
|
|
for (p = packed_git; p && !ds->ambiguous; p = p->next)
|
2016-09-26 20:00:04 +08:00
|
|
|
unique_in_pack(p, ds);
|
2005-10-03 12:40:51 +08:00
|
|
|
}
|
|
|
|
|
2005-10-12 06:22:48 +08:00
|
|
|
#define SHORT_NAME_NOT_FOUND (-1)
|
|
|
|
#define SHORT_NAME_AMBIGUOUS (-2)
|
|
|
|
|
2012-06-21 13:07:36 +08:00
|
|
|
static int finish_object_disambiguation(struct disambiguate_state *ds,
|
|
|
|
unsigned char *sha1)
|
2005-10-03 12:40:51 +08:00
|
|
|
{
|
2012-06-21 13:07:36 +08:00
|
|
|
if (ds->ambiguous)
|
|
|
|
return SHORT_NAME_AMBIGUOUS;
|
2005-10-03 12:40:51 +08:00
|
|
|
|
2012-06-21 13:07:36 +08:00
|
|
|
if (!ds->candidate_exists)
|
2005-10-12 06:22:48 +08:00
|
|
|
return SHORT_NAME_NOT_FOUND;
|
2012-06-21 13:07:36 +08:00
|
|
|
|
|
|
|
if (!ds->candidate_checked)
|
|
|
|
/*
|
|
|
|
* If this is the only candidate, there is no point
|
|
|
|
* calling the disambiguation hint callback.
|
|
|
|
*
|
|
|
|
* On the other hand, if the current candidate
|
|
|
|
* replaced an earlier candidate that did _not_ pass
|
|
|
|
* the disambiguation hint callback, then we do have
|
|
|
|
* more than one objects that match the short name
|
|
|
|
* given, so we should make sure this one matches;
|
|
|
|
* otherwise, if we discovered this one and the one
|
|
|
|
* that we previously discarded in the reverse order,
|
|
|
|
* we would end up showing different results in the
|
|
|
|
* same repository!
|
|
|
|
*/
|
|
|
|
ds->candidate_ok = (!ds->disambiguate_fn_used ||
|
2017-03-27 00:01:34 +08:00
|
|
|
ds->fn(&ds->candidate, ds->cb_data));
|
2012-06-21 13:07:36 +08:00
|
|
|
|
|
|
|
if (!ds->candidate_ok)
|
2005-10-12 06:22:48 +08:00
|
|
|
return SHORT_NAME_AMBIGUOUS;
|
2012-06-21 13:07:36 +08:00
|
|
|
|
2017-03-27 00:01:33 +08:00
|
|
|
hashcpy(sha1, ds->candidate.hash);
|
2005-08-04 13:15:49 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
static int disambiguate_commit_only(const struct object_id *oid, void *cb_data_unused)
|
2012-06-21 14:03:09 +08:00
|
|
|
{
|
2017-03-27 00:01:34 +08:00
|
|
|
int kind = sha1_object_info(oid->hash, NULL);
|
2012-06-21 14:03:09 +08:00
|
|
|
return kind == OBJ_COMMIT;
|
|
|
|
}
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
static int disambiguate_committish_only(const struct object_id *oid, void *cb_data_unused)
|
2012-07-03 01:00:40 +08:00
|
|
|
{
|
|
|
|
struct object *obj;
|
|
|
|
int kind;
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
kind = sha1_object_info(oid->hash, NULL);
|
2012-07-03 01:00:40 +08:00
|
|
|
if (kind == OBJ_COMMIT)
|
|
|
|
return 1;
|
|
|
|
if (kind != OBJ_TAG)
|
2005-10-03 12:40:51 +08:00
|
|
|
return 0;
|
2012-07-03 01:00:40 +08:00
|
|
|
|
|
|
|
/* We need to do this the hard way... */
|
2017-03-27 00:01:34 +08:00
|
|
|
obj = deref_tag(parse_object(oid->hash), NULL, 0);
|
2012-07-03 01:00:40 +08:00
|
|
|
if (obj && obj->type == OBJ_COMMIT)
|
|
|
|
return 1;
|
2005-08-04 13:15:49 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
static int disambiguate_tree_only(const struct object_id *oid, void *cb_data_unused)
|
2005-08-04 13:15:49 +08:00
|
|
|
{
|
2017-03-27 00:01:34 +08:00
|
|
|
int kind = sha1_object_info(oid->hash, NULL);
|
2012-07-03 14:35:05 +08:00
|
|
|
return kind == OBJ_TREE;
|
|
|
|
}
|
2005-08-04 13:15:49 +08:00
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
static int disambiguate_treeish_only(const struct object_id *oid, void *cb_data_unused)
|
2012-07-03 14:35:05 +08:00
|
|
|
{
|
|
|
|
struct object *obj;
|
|
|
|
int kind;
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
kind = sha1_object_info(oid->hash, NULL);
|
2012-07-03 14:35:05 +08:00
|
|
|
if (kind == OBJ_TREE || kind == OBJ_COMMIT)
|
|
|
|
return 1;
|
|
|
|
if (kind != OBJ_TAG)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* We need to do this the hard way... */
|
2017-03-27 00:01:34 +08:00
|
|
|
obj = deref_tag(parse_object(oid->hash), NULL, 0);
|
2012-07-03 14:35:05 +08:00
|
|
|
if (obj && (obj->type == OBJ_TREE || obj->type == OBJ_COMMIT))
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
static int disambiguate_blob_only(const struct object_id *oid, void *cb_data_unused)
|
2012-07-03 14:35:05 +08:00
|
|
|
{
|
2017-03-27 00:01:34 +08:00
|
|
|
int kind = sha1_object_info(oid->hash, NULL);
|
2012-07-03 14:35:05 +08:00
|
|
|
return kind == OBJ_BLOB;
|
|
|
|
}
|
|
|
|
|
2016-09-27 20:38:01 +08:00
|
|
|
static disambiguate_hint_fn default_disambiguate_hint;
|
|
|
|
|
|
|
|
int set_disambiguate_hint_config(const char *var, const char *value)
|
|
|
|
{
|
|
|
|
static const struct {
|
|
|
|
const char *name;
|
|
|
|
disambiguate_hint_fn fn;
|
|
|
|
} hints[] = {
|
|
|
|
{ "none", NULL },
|
|
|
|
{ "commit", disambiguate_commit_only },
|
|
|
|
{ "committish", disambiguate_committish_only },
|
|
|
|
{ "tree", disambiguate_tree_only },
|
|
|
|
{ "treeish", disambiguate_treeish_only },
|
|
|
|
{ "blob", disambiguate_blob_only }
|
|
|
|
};
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(hints); i++) {
|
|
|
|
if (!strcasecmp(value, hints[i].name)) {
|
|
|
|
default_disambiguate_hint = hints[i].fn;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return error("unknown hint type for '%s': %s", var, value);
|
|
|
|
}
|
|
|
|
|
2016-09-26 20:00:04 +08:00
|
|
|
static int init_object_disambiguation(const char *name, int len,
|
|
|
|
struct disambiguate_state *ds)
|
2005-08-04 13:15:49 +08:00
|
|
|
{
|
2012-07-04 05:21:59 +08:00
|
|
|
int i;
|
2005-08-04 13:15:49 +08:00
|
|
|
|
2016-09-26 20:00:04 +08:00
|
|
|
if (len < MINIMUM_ABBREV || len > GIT_SHA1_HEXSZ)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
memset(ds, 0, sizeof(*ds));
|
|
|
|
|
2005-09-20 06:16:03 +08:00
|
|
|
for (i = 0; i < len ;i++) {
|
2005-08-04 13:15:49 +08:00
|
|
|
unsigned char c = name[i];
|
|
|
|
unsigned char val;
|
|
|
|
if (c >= '0' && c <= '9')
|
|
|
|
val = c - '0';
|
|
|
|
else if (c >= 'a' && c <= 'f')
|
|
|
|
val = c - 'a' + 10;
|
|
|
|
else if (c >= 'A' && c <='F') {
|
|
|
|
val = c - 'A' + 10;
|
|
|
|
c -= 'A' - 'a';
|
|
|
|
}
|
|
|
|
else
|
|
|
|
return -1;
|
2016-09-26 20:00:04 +08:00
|
|
|
ds->hex_pfx[i] = c;
|
2005-08-04 13:15:49 +08:00
|
|
|
if (!(i & 1))
|
|
|
|
val <<= 4;
|
2017-03-27 00:01:33 +08:00
|
|
|
ds->bin_pfx.hash[i >> 1] |= val;
|
2005-08-04 13:15:49 +08:00
|
|
|
}
|
2016-09-26 20:00:04 +08:00
|
|
|
|
|
|
|
ds->len = len;
|
2016-09-26 20:00:07 +08:00
|
|
|
ds->hex_pfx[len] = '\0';
|
2016-09-26 20:00:04 +08:00
|
|
|
prepare_alt_odb();
|
2012-07-04 05:21:59 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-31 09:39:59 +08:00
|
|
|
static int show_ambiguous_object(const struct object_id *oid, void *data)
|
get_short_sha1: list ambiguous objects on error
When the user gives us an ambiguous short sha1, we print an
error and refuse to resolve it. In some cases, the next step
is for them to feed us more characters (e.g., if they were
retyping or cut-and-pasting from a full sha1). But in other
cases, that might be all they have. For example, an old
commit message may have used a 7-character hex that was
unique at the time, but is now ambiguous. Git doesn't
provide any information about the ambiguous objects it
found, so it's hard for the user to find out which one they
probably meant.
This patch teaches get_short_sha1() to list the sha1s of the
objects it found, along with a few bits of information that
may help the user decide which one they meant. Here's what
it looks like on git.git:
$ git rev-parse b2e1
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
hint: b2e1759 blob
hint: b2e18954 blob
hint: b2e1895c blob
fatal: ambiguous argument 'b2e1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
We show the tagname for tags, and the date and subject for
commits. For trees and blobs, in theory we could dig in the
history to find the paths at which they were present. But
that's very expensive (on the order of 30s for the kernel),
and it's not likely to be all that helpful. Most short
references are to commits, so the useful information is
typically going to be that the object in question _isn't_ a
commit. So it's silly to spend a lot of CPU preemptively
digging up the path; the user can do it themselves if they
really need to.
And of course it's somewhat ironic that we abbreviate the
sha1s in the disambiguation hint. But full sha1s would cause
annoying line wrapping for the commit lines, and presumably
the user is going to just re-issue their command immediately
with the corrected sha1.
We also restrict the list to those that match any
disambiguation hint. E.g.:
$ git rev-parse b2e1:foo
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
fatal: Invalid object name 'b2e1'.
does not bother reporting the blobs, because they cannot
work as a treeish.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26 20:00:36 +08:00
|
|
|
{
|
|
|
|
const struct disambiguate_state *ds = data;
|
|
|
|
struct strbuf desc = STRBUF_INIT;
|
|
|
|
int type;
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
|
2017-03-31 09:39:59 +08:00
|
|
|
if (ds->fn && !ds->fn(oid, ds->cb_data))
|
get_short_sha1: list ambiguous objects on error
When the user gives us an ambiguous short sha1, we print an
error and refuse to resolve it. In some cases, the next step
is for them to feed us more characters (e.g., if they were
retyping or cut-and-pasting from a full sha1). But in other
cases, that might be all they have. For example, an old
commit message may have used a 7-character hex that was
unique at the time, but is now ambiguous. Git doesn't
provide any information about the ambiguous objects it
found, so it's hard for the user to find out which one they
probably meant.
This patch teaches get_short_sha1() to list the sha1s of the
objects it found, along with a few bits of information that
may help the user decide which one they meant. Here's what
it looks like on git.git:
$ git rev-parse b2e1
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
hint: b2e1759 blob
hint: b2e18954 blob
hint: b2e1895c blob
fatal: ambiguous argument 'b2e1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
We show the tagname for tags, and the date and subject for
commits. For trees and blobs, in theory we could dig in the
history to find the paths at which they were present. But
that's very expensive (on the order of 30s for the kernel),
and it's not likely to be all that helpful. Most short
references are to commits, so the useful information is
typically going to be that the object in question _isn't_ a
commit. So it's silly to spend a lot of CPU preemptively
digging up the path; the user can do it themselves if they
really need to.
And of course it's somewhat ironic that we abbreviate the
sha1s in the disambiguation hint. But full sha1s would cause
annoying line wrapping for the commit lines, and presumably
the user is going to just re-issue their command immediately
with the corrected sha1.
We also restrict the list to those that match any
disambiguation hint. E.g.:
$ git rev-parse b2e1:foo
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
fatal: Invalid object name 'b2e1'.
does not bother reporting the blobs, because they cannot
work as a treeish.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26 20:00:36 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-03-31 09:39:59 +08:00
|
|
|
type = sha1_object_info(oid->hash, NULL);
|
get_short_sha1: list ambiguous objects on error
When the user gives us an ambiguous short sha1, we print an
error and refuse to resolve it. In some cases, the next step
is for them to feed us more characters (e.g., if they were
retyping or cut-and-pasting from a full sha1). But in other
cases, that might be all they have. For example, an old
commit message may have used a 7-character hex that was
unique at the time, but is now ambiguous. Git doesn't
provide any information about the ambiguous objects it
found, so it's hard for the user to find out which one they
probably meant.
This patch teaches get_short_sha1() to list the sha1s of the
objects it found, along with a few bits of information that
may help the user decide which one they meant. Here's what
it looks like on git.git:
$ git rev-parse b2e1
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
hint: b2e1759 blob
hint: b2e18954 blob
hint: b2e1895c blob
fatal: ambiguous argument 'b2e1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
We show the tagname for tags, and the date and subject for
commits. For trees and blobs, in theory we could dig in the
history to find the paths at which they were present. But
that's very expensive (on the order of 30s for the kernel),
and it's not likely to be all that helpful. Most short
references are to commits, so the useful information is
typically going to be that the object in question _isn't_ a
commit. So it's silly to spend a lot of CPU preemptively
digging up the path; the user can do it themselves if they
really need to.
And of course it's somewhat ironic that we abbreviate the
sha1s in the disambiguation hint. But full sha1s would cause
annoying line wrapping for the commit lines, and presumably
the user is going to just re-issue their command immediately
with the corrected sha1.
We also restrict the list to those that match any
disambiguation hint. E.g.:
$ git rev-parse b2e1:foo
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
fatal: Invalid object name 'b2e1'.
does not bother reporting the blobs, because they cannot
work as a treeish.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26 20:00:36 +08:00
|
|
|
if (type == OBJ_COMMIT) {
|
2017-03-31 09:39:59 +08:00
|
|
|
struct commit *commit = lookup_commit(oid->hash);
|
get_short_sha1: list ambiguous objects on error
When the user gives us an ambiguous short sha1, we print an
error and refuse to resolve it. In some cases, the next step
is for them to feed us more characters (e.g., if they were
retyping or cut-and-pasting from a full sha1). But in other
cases, that might be all they have. For example, an old
commit message may have used a 7-character hex that was
unique at the time, but is now ambiguous. Git doesn't
provide any information about the ambiguous objects it
found, so it's hard for the user to find out which one they
probably meant.
This patch teaches get_short_sha1() to list the sha1s of the
objects it found, along with a few bits of information that
may help the user decide which one they meant. Here's what
it looks like on git.git:
$ git rev-parse b2e1
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
hint: b2e1759 blob
hint: b2e18954 blob
hint: b2e1895c blob
fatal: ambiguous argument 'b2e1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
We show the tagname for tags, and the date and subject for
commits. For trees and blobs, in theory we could dig in the
history to find the paths at which they were present. But
that's very expensive (on the order of 30s for the kernel),
and it's not likely to be all that helpful. Most short
references are to commits, so the useful information is
typically going to be that the object in question _isn't_ a
commit. So it's silly to spend a lot of CPU preemptively
digging up the path; the user can do it themselves if they
really need to.
And of course it's somewhat ironic that we abbreviate the
sha1s in the disambiguation hint. But full sha1s would cause
annoying line wrapping for the commit lines, and presumably
the user is going to just re-issue their command immediately
with the corrected sha1.
We also restrict the list to those that match any
disambiguation hint. E.g.:
$ git rev-parse b2e1:foo
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
fatal: Invalid object name 'b2e1'.
does not bother reporting the blobs, because they cannot
work as a treeish.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26 20:00:36 +08:00
|
|
|
if (commit) {
|
|
|
|
struct pretty_print_context pp = {0};
|
|
|
|
pp.date_mode.type = DATE_SHORT;
|
|
|
|
format_commit_message(commit, " %ad - %s", &desc, &pp);
|
|
|
|
}
|
|
|
|
} else if (type == OBJ_TAG) {
|
2017-03-31 09:39:59 +08:00
|
|
|
struct tag *tag = lookup_tag(oid->hash);
|
get_short_sha1: list ambiguous objects on error
When the user gives us an ambiguous short sha1, we print an
error and refuse to resolve it. In some cases, the next step
is for them to feed us more characters (e.g., if they were
retyping or cut-and-pasting from a full sha1). But in other
cases, that might be all they have. For example, an old
commit message may have used a 7-character hex that was
unique at the time, but is now ambiguous. Git doesn't
provide any information about the ambiguous objects it
found, so it's hard for the user to find out which one they
probably meant.
This patch teaches get_short_sha1() to list the sha1s of the
objects it found, along with a few bits of information that
may help the user decide which one they meant. Here's what
it looks like on git.git:
$ git rev-parse b2e1
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
hint: b2e1759 blob
hint: b2e18954 blob
hint: b2e1895c blob
fatal: ambiguous argument 'b2e1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
We show the tagname for tags, and the date and subject for
commits. For trees and blobs, in theory we could dig in the
history to find the paths at which they were present. But
that's very expensive (on the order of 30s for the kernel),
and it's not likely to be all that helpful. Most short
references are to commits, so the useful information is
typically going to be that the object in question _isn't_ a
commit. So it's silly to spend a lot of CPU preemptively
digging up the path; the user can do it themselves if they
really need to.
And of course it's somewhat ironic that we abbreviate the
sha1s in the disambiguation hint. But full sha1s would cause
annoying line wrapping for the commit lines, and presumably
the user is going to just re-issue their command immediately
with the corrected sha1.
We also restrict the list to those that match any
disambiguation hint. E.g.:
$ git rev-parse b2e1:foo
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
fatal: Invalid object name 'b2e1'.
does not bother reporting the blobs, because they cannot
work as a treeish.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26 20:00:36 +08:00
|
|
|
if (!parse_tag(tag) && tag->tag)
|
|
|
|
strbuf_addf(&desc, " %s", tag->tag);
|
|
|
|
}
|
|
|
|
|
|
|
|
advise(" %s %s%s",
|
2017-03-31 09:39:59 +08:00
|
|
|
find_unique_abbrev(oid->hash, DEFAULT_ABBREV),
|
get_short_sha1: list ambiguous objects on error
When the user gives us an ambiguous short sha1, we print an
error and refuse to resolve it. In some cases, the next step
is for them to feed us more characters (e.g., if they were
retyping or cut-and-pasting from a full sha1). But in other
cases, that might be all they have. For example, an old
commit message may have used a 7-character hex that was
unique at the time, but is now ambiguous. Git doesn't
provide any information about the ambiguous objects it
found, so it's hard for the user to find out which one they
probably meant.
This patch teaches get_short_sha1() to list the sha1s of the
objects it found, along with a few bits of information that
may help the user decide which one they meant. Here's what
it looks like on git.git:
$ git rev-parse b2e1
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
hint: b2e1759 blob
hint: b2e18954 blob
hint: b2e1895c blob
fatal: ambiguous argument 'b2e1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
We show the tagname for tags, and the date and subject for
commits. For trees and blobs, in theory we could dig in the
history to find the paths at which they were present. But
that's very expensive (on the order of 30s for the kernel),
and it's not likely to be all that helpful. Most short
references are to commits, so the useful information is
typically going to be that the object in question _isn't_ a
commit. So it's silly to spend a lot of CPU preemptively
digging up the path; the user can do it themselves if they
really need to.
And of course it's somewhat ironic that we abbreviate the
sha1s in the disambiguation hint. But full sha1s would cause
annoying line wrapping for the commit lines, and presumably
the user is going to just re-issue their command immediately
with the corrected sha1.
We also restrict the list to those that match any
disambiguation hint. E.g.:
$ git rev-parse b2e1:foo
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
fatal: Invalid object name 'b2e1'.
does not bother reporting the blobs, because they cannot
work as a treeish.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26 20:00:36 +08:00
|
|
|
typename(type) ? typename(type) : "unknown type",
|
|
|
|
desc.buf);
|
|
|
|
|
|
|
|
strbuf_release(&desc);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-07-04 05:21:59 +08:00
|
|
|
static int get_short_sha1(const char *name, int len, unsigned char *sha1,
|
|
|
|
unsigned flags)
|
|
|
|
{
|
|
|
|
int status;
|
|
|
|
struct disambiguate_state ds;
|
|
|
|
int quietly = !!(flags & GET_SHA1_QUIETLY);
|
|
|
|
|
2016-09-26 20:00:04 +08:00
|
|
|
if (init_object_disambiguation(name, len, &ds) < 0)
|
2012-07-04 05:21:59 +08:00
|
|
|
return -1;
|
2005-10-03 12:40:51 +08:00
|
|
|
|
2016-09-26 19:59:01 +08:00
|
|
|
if (HAS_MULTI_BITS(flags & GET_SHA1_DISAMBIGUATORS))
|
|
|
|
die("BUG: multiple get_short_sha1 disambiguator flags");
|
|
|
|
|
2012-06-21 14:03:09 +08:00
|
|
|
if (flags & GET_SHA1_COMMIT)
|
|
|
|
ds.fn = disambiguate_commit_only;
|
2012-07-03 01:00:40 +08:00
|
|
|
else if (flags & GET_SHA1_COMMITTISH)
|
|
|
|
ds.fn = disambiguate_committish_only;
|
2012-07-03 14:35:05 +08:00
|
|
|
else if (flags & GET_SHA1_TREE)
|
|
|
|
ds.fn = disambiguate_tree_only;
|
|
|
|
else if (flags & GET_SHA1_TREEISH)
|
|
|
|
ds.fn = disambiguate_treeish_only;
|
|
|
|
else if (flags & GET_SHA1_BLOB)
|
|
|
|
ds.fn = disambiguate_blob_only;
|
2016-09-27 20:38:01 +08:00
|
|
|
else
|
|
|
|
ds.fn = default_disambiguate_hint;
|
2012-06-21 14:03:09 +08:00
|
|
|
|
2016-09-26 20:00:04 +08:00
|
|
|
find_short_object_filename(&ds);
|
|
|
|
find_short_packed_object(&ds);
|
2012-06-21 13:07:36 +08:00
|
|
|
status = finish_object_disambiguation(&ds, sha1);
|
2005-10-03 12:40:51 +08:00
|
|
|
|
get_short_sha1: list ambiguous objects on error
When the user gives us an ambiguous short sha1, we print an
error and refuse to resolve it. In some cases, the next step
is for them to feed us more characters (e.g., if they were
retyping or cut-and-pasting from a full sha1). But in other
cases, that might be all they have. For example, an old
commit message may have used a 7-character hex that was
unique at the time, but is now ambiguous. Git doesn't
provide any information about the ambiguous objects it
found, so it's hard for the user to find out which one they
probably meant.
This patch teaches get_short_sha1() to list the sha1s of the
objects it found, along with a few bits of information that
may help the user decide which one they meant. Here's what
it looks like on git.git:
$ git rev-parse b2e1
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
hint: b2e1759 blob
hint: b2e18954 blob
hint: b2e1895c blob
fatal: ambiguous argument 'b2e1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
We show the tagname for tags, and the date and subject for
commits. For trees and blobs, in theory we could dig in the
history to find the paths at which they were present. But
that's very expensive (on the order of 30s for the kernel),
and it's not likely to be all that helpful. Most short
references are to commits, so the useful information is
typically going to be that the object in question _isn't_ a
commit. So it's silly to spend a lot of CPU preemptively
digging up the path; the user can do it themselves if they
really need to.
And of course it's somewhat ironic that we abbreviate the
sha1s in the disambiguation hint. But full sha1s would cause
annoying line wrapping for the commit lines, and presumably
the user is going to just re-issue their command immediately
with the corrected sha1.
We also restrict the list to those that match any
disambiguation hint. E.g.:
$ git rev-parse b2e1:foo
error: short SHA1 b2e1 is ambiguous
hint: The candidates are:
hint: b2e1196 tag v2.8.0-rc1
hint: b2e11d1 tree
hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
fatal: Invalid object name 'b2e1'.
does not bother reporting the blobs, because they cannot
work as a treeish.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26 20:00:36 +08:00
|
|
|
if (!quietly && (status == SHORT_NAME_AMBIGUOUS)) {
|
|
|
|
error(_("short SHA1 %s is ambiguous"), ds.hex_pfx);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We may still have ambiguity if we simply saw a series of
|
|
|
|
* candidates that did not satisfy our hint function. In
|
|
|
|
* that case, we still want to show them, so disable the hint
|
|
|
|
* function entirely.
|
|
|
|
*/
|
|
|
|
if (!ds.ambiguous)
|
|
|
|
ds.fn = NULL;
|
|
|
|
|
|
|
|
advise(_("The candidates are:"));
|
|
|
|
for_each_abbrev(ds.hex_pfx, show_ambiguous_object, &ds);
|
|
|
|
}
|
|
|
|
|
2005-10-12 06:22:48 +08:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2017-03-27 00:01:34 +08:00
|
|
|
static int collect_ambiguous(const struct object_id *oid, void *data)
|
2016-09-26 20:00:33 +08:00
|
|
|
{
|
2017-03-31 09:40:00 +08:00
|
|
|
oid_array_append(data, oid);
|
2016-09-26 20:00:33 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-07-04 05:21:59 +08:00
|
|
|
int for_each_abbrev(const char *prefix, each_abbrev_fn fn, void *cb_data)
|
|
|
|
{
|
2017-03-31 09:40:00 +08:00
|
|
|
struct oid_array collect = OID_ARRAY_INIT;
|
2012-07-04 05:21:59 +08:00
|
|
|
struct disambiguate_state ds;
|
2016-09-26 20:00:33 +08:00
|
|
|
int ret;
|
2012-07-04 05:21:59 +08:00
|
|
|
|
2016-09-26 20:00:04 +08:00
|
|
|
if (init_object_disambiguation(prefix, strlen(prefix), &ds) < 0)
|
2012-07-04 05:21:59 +08:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
ds.always_call_fn = 1;
|
2016-09-26 20:00:33 +08:00
|
|
|
ds.fn = collect_ambiguous;
|
|
|
|
ds.cb_data = &collect;
|
2016-09-26 20:00:04 +08:00
|
|
|
find_short_object_filename(&ds);
|
|
|
|
find_short_packed_object(&ds);
|
2016-09-26 20:00:33 +08:00
|
|
|
|
2017-03-31 09:40:00 +08:00
|
|
|
ret = oid_array_for_each_unique(&collect, fn, cb_data);
|
|
|
|
oid_array_clear(&collect);
|
2016-09-26 20:00:33 +08:00
|
|
|
return ret;
|
2012-07-04 05:21:59 +08:00
|
|
|
}
|
|
|
|
|
2016-10-04 07:47:28 +08:00
|
|
|
/*
|
|
|
|
* Return the slot of the most-significant bit set in "val". There are various
|
|
|
|
* ways to do this quickly with fls() or __builtin_clzl(), but speed is
|
|
|
|
* probably not a big deal here.
|
|
|
|
*/
|
|
|
|
static unsigned msb(unsigned long val)
|
|
|
|
{
|
|
|
|
unsigned r = 0;
|
|
|
|
while (val >>= 1)
|
|
|
|
r++;
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2015-09-25 05:05:45 +08:00
|
|
|
int find_unique_abbrev_r(char *hex, const unsigned char *sha1, int len)
|
2005-10-12 06:22:48 +08:00
|
|
|
{
|
2008-03-02 15:35:32 +08:00
|
|
|
int status, exists;
|
2005-12-14 09:21:41 +08:00
|
|
|
|
2016-10-01 08:19:37 +08:00
|
|
|
if (len < 0) {
|
2016-10-04 07:47:28 +08:00
|
|
|
unsigned long count = approximate_object_count();
|
|
|
|
/*
|
|
|
|
* Add one because the MSB only tells us the highest bit set,
|
|
|
|
* not including the value of all the _other_ bits (so "15"
|
|
|
|
* is only one off of 2^4, but the MSB is the 3rd bit.
|
|
|
|
*/
|
|
|
|
len = msb(count) + 1;
|
|
|
|
/*
|
|
|
|
* We now know we have on the order of 2^len objects, which
|
|
|
|
* expects a collision at 2^(len/2). But we also care about hex
|
|
|
|
* chars, not bits, and there are 4 bits per hex. So all
|
|
|
|
* together we need to divide by 2; but we also want to round
|
|
|
|
* odd numbers up, hence adding one before dividing.
|
|
|
|
*/
|
|
|
|
len = (len + 1) / 2;
|
|
|
|
/*
|
|
|
|
* For very small repos, we stick with our regular fallback.
|
|
|
|
*/
|
|
|
|
if (len < FALLBACK_DEFAULT_ABBREV)
|
|
|
|
len = FALLBACK_DEFAULT_ABBREV;
|
2016-10-01 08:19:37 +08:00
|
|
|
}
|
2016-10-04 07:47:28 +08:00
|
|
|
|
2015-09-25 05:05:45 +08:00
|
|
|
sha1_to_hex_r(hex, sha1);
|
2006-08-10 04:17:04 +08:00
|
|
|
if (len == 40 || !len)
|
2015-09-25 05:05:45 +08:00
|
|
|
return 40;
|
2014-11-26 18:12:47 +08:00
|
|
|
exists = has_sha1_file(sha1);
|
2005-10-12 06:22:48 +08:00
|
|
|
while (len < 40) {
|
|
|
|
unsigned char sha1_ret[20];
|
2016-10-04 07:47:28 +08:00
|
|
|
status = get_short_sha1(hex, len, sha1_ret, GET_SHA1_QUIETLY);
|
2008-03-02 15:35:32 +08:00
|
|
|
if (exists
|
|
|
|
? !status
|
|
|
|
: status == SHORT_NAME_NOT_FOUND) {
|
2011-03-11 14:41:14 +08:00
|
|
|
hex[len] = 0;
|
2015-09-25 05:05:45 +08:00
|
|
|
return len;
|
2005-10-12 06:22:48 +08:00
|
|
|
}
|
|
|
|
len++;
|
|
|
|
}
|
2015-09-25 05:05:45 +08:00
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *find_unique_abbrev(const unsigned char *sha1, int len)
|
|
|
|
{
|
2016-10-20 14:19:19 +08:00
|
|
|
static int bufno;
|
2017-03-27 00:01:24 +08:00
|
|
|
static char hexbuffer[4][GIT_MAX_HEXSZ + 1];
|
2016-11-01 16:49:07 +08:00
|
|
|
char *hex = hexbuffer[bufno];
|
|
|
|
bufno = (bufno + 1) % ARRAY_SIZE(hexbuffer);
|
2015-09-25 05:05:45 +08:00
|
|
|
find_unique_abbrev_r(hex, sha1, len);
|
2008-03-02 15:35:32 +08:00
|
|
|
return hex;
|
2005-08-04 13:15:49 +08:00
|
|
|
}
|
|
|
|
|
2005-12-16 04:54:00 +08:00
|
|
|
static int ambiguous_path(const char *path, int len)
|
Be more careful about reference parsing
This does two things:
- we don't allow "." and ".." as components of a refname. Thus get_sha1()
will not accept "./refname" as being the same as "refname" any more.
- git-rev-parse stops doing revision translation after seeing a pathname,
to match the brhaviour of all the tools (once we see a pathname,
everything else will also be parsed as a pathname).
Basically, if you did
git log *
and "gitk" was somewhere in the "*", we don't want to replace the filename
"gitk" with the SHA1 of the branch with the same name.
Of course, if there is any change of ambiguity, you should always use "--"
to make it explicit what are filenames and what are revisions, but this
makes the normal cases sane. The refname rule also means that instead of
the "--", you can do the same thing we're used to doing with filenames
that start with a slash: use "./filename" instead, and now it's a
filename, not an option (and not a revision).
So "git log ./*.c" is now actually a perfectly valid thing to do, even if
the first C-file might have the same name as a branch.
Trivial test:
git-rev-parse gitk ./gitk gitk
should output something like
9843c3074dfbf57117565f6b7c93e3e6812857ee
./gitk
gitk
where the "./gitk" isn't seen as a revision, and the second "gitk" is a
filename simply because we've seen filenames already, and thus stopped
doing revision parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-29 03:41:49 +08:00
|
|
|
{
|
|
|
|
int slash = 1;
|
2005-12-16 04:54:00 +08:00
|
|
|
int cnt;
|
Be more careful about reference parsing
This does two things:
- we don't allow "." and ".." as components of a refname. Thus get_sha1()
will not accept "./refname" as being the same as "refname" any more.
- git-rev-parse stops doing revision translation after seeing a pathname,
to match the brhaviour of all the tools (once we see a pathname,
everything else will also be parsed as a pathname).
Basically, if you did
git log *
and "gitk" was somewhere in the "*", we don't want to replace the filename
"gitk" with the SHA1 of the branch with the same name.
Of course, if there is any change of ambiguity, you should always use "--"
to make it explicit what are filenames and what are revisions, but this
makes the normal cases sane. The refname rule also means that instead of
the "--", you can do the same thing we're used to doing with filenames
that start with a slash: use "./filename" instead, and now it's a
filename, not an option (and not a revision).
So "git log ./*.c" is now actually a perfectly valid thing to do, even if
the first C-file might have the same name as a branch.
Trivial test:
git-rev-parse gitk ./gitk gitk
should output something like
9843c3074dfbf57117565f6b7c93e3e6812857ee
./gitk
gitk
where the "./gitk" isn't seen as a revision, and the second "gitk" is a
filename simply because we've seen filenames already, and thus stopped
doing revision parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-29 03:41:49 +08:00
|
|
|
|
2005-12-16 04:54:00 +08:00
|
|
|
for (cnt = 0; cnt < len; cnt++) {
|
Be more careful about reference parsing
This does two things:
- we don't allow "." and ".." as components of a refname. Thus get_sha1()
will not accept "./refname" as being the same as "refname" any more.
- git-rev-parse stops doing revision translation after seeing a pathname,
to match the brhaviour of all the tools (once we see a pathname,
everything else will also be parsed as a pathname).
Basically, if you did
git log *
and "gitk" was somewhere in the "*", we don't want to replace the filename
"gitk" with the SHA1 of the branch with the same name.
Of course, if there is any change of ambiguity, you should always use "--"
to make it explicit what are filenames and what are revisions, but this
makes the normal cases sane. The refname rule also means that instead of
the "--", you can do the same thing we're used to doing with filenames
that start with a slash: use "./filename" instead, and now it's a
filename, not an option (and not a revision).
So "git log ./*.c" is now actually a perfectly valid thing to do, even if
the first C-file might have the same name as a branch.
Trivial test:
git-rev-parse gitk ./gitk gitk
should output something like
9843c3074dfbf57117565f6b7c93e3e6812857ee
./gitk
gitk
where the "./gitk" isn't seen as a revision, and the second "gitk" is a
filename simply because we've seen filenames already, and thus stopped
doing revision parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-29 03:41:49 +08:00
|
|
|
switch (*path++) {
|
|
|
|
case '\0':
|
|
|
|
break;
|
|
|
|
case '/':
|
|
|
|
if (slash)
|
|
|
|
break;
|
|
|
|
slash = 1;
|
|
|
|
continue;
|
|
|
|
case '.':
|
|
|
|
continue;
|
|
|
|
default:
|
|
|
|
slash = 0;
|
|
|
|
continue;
|
|
|
|
}
|
2005-12-17 16:00:50 +08:00
|
|
|
break;
|
Be more careful about reference parsing
This does two things:
- we don't allow "." and ".." as components of a refname. Thus get_sha1()
will not accept "./refname" as being the same as "refname" any more.
- git-rev-parse stops doing revision translation after seeing a pathname,
to match the brhaviour of all the tools (once we see a pathname,
everything else will also be parsed as a pathname).
Basically, if you did
git log *
and "gitk" was somewhere in the "*", we don't want to replace the filename
"gitk" with the SHA1 of the branch with the same name.
Of course, if there is any change of ambiguity, you should always use "--"
to make it explicit what are filenames and what are revisions, but this
makes the normal cases sane. The refname rule also means that instead of
the "--", you can do the same thing we're used to doing with filenames
that start with a slash: use "./filename" instead, and now it's a
filename, not an option (and not a revision).
So "git log ./*.c" is now actually a perfectly valid thing to do, even if
the first C-file might have the same name as a branch.
Trivial test:
git-rev-parse gitk ./gitk gitk
should output something like
9843c3074dfbf57117565f6b7c93e3e6812857ee
./gitk
gitk
where the "./gitk" isn't seen as a revision, and the second "gitk" is a
filename simply because we've seen filenames already, and thus stopped
doing revision parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-29 03:41:49 +08:00
|
|
|
}
|
2005-12-16 04:54:00 +08:00
|
|
|
return slash;
|
Be more careful about reference parsing
This does two things:
- we don't allow "." and ".." as components of a refname. Thus get_sha1()
will not accept "./refname" as being the same as "refname" any more.
- git-rev-parse stops doing revision translation after seeing a pathname,
to match the brhaviour of all the tools (once we see a pathname,
everything else will also be parsed as a pathname).
Basically, if you did
git log *
and "gitk" was somewhere in the "*", we don't want to replace the filename
"gitk" with the SHA1 of the branch with the same name.
Of course, if there is any change of ambiguity, you should always use "--"
to make it explicit what are filenames and what are revisions, but this
makes the normal cases sane. The refname rule also means that instead of
the "--", you can do the same thing we're used to doing with filenames
that start with a slash: use "./filename" instead, and now it's a
filename, not an option (and not a revision).
So "git log ./*.c" is now actually a perfectly valid thing to do, even if
the first C-file might have the same name as a branch.
Trivial test:
git-rev-parse gitk ./gitk gitk
should output something like
9843c3074dfbf57117565f6b7c93e3e6812857ee
./gitk
gitk
where the "./gitk" isn't seen as a revision, and the second "gitk" is a
filename simply because we've seen filenames already, and thus stopped
doing revision parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-29 03:41:49 +08:00
|
|
|
}
|
|
|
|
|
2015-05-21 12:45:39 +08:00
|
|
|
static inline int at_mark(const char *string, int len,
|
|
|
|
const char **suffix, int nr)
|
2010-01-20 15:17:11 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2015-05-21 12:45:39 +08:00
|
|
|
for (i = 0; i < nr; i++) {
|
2010-01-20 15:17:11 +08:00
|
|
|
int suffix_len = strlen(suffix[i]);
|
|
|
|
if (suffix_len <= len
|
2017-03-27 19:16:55 +08:00
|
|
|
&& !strncasecmp(string, suffix[i], suffix_len))
|
2010-01-20 15:17:11 +08:00
|
|
|
return suffix_len;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-05-21 12:45:39 +08:00
|
|
|
static inline int upstream_mark(const char *string, int len)
|
|
|
|
{
|
|
|
|
const char *suffix[] = { "@{upstream}", "@{u}" };
|
|
|
|
return at_mark(string, len, suffix, ARRAY_SIZE(suffix));
|
|
|
|
}
|
|
|
|
|
sha1_name: implement @{push} shorthand
In a triangular workflow, each branch may have two distinct
points of interest: the @{upstream} that you normally pull
from, and the destination that you normally push to. There
isn't a shorthand for the latter, but it's useful to have.
For instance, you may want to know which commits you haven't
pushed yet:
git log @{push}..
Or as a more complicated example, imagine that you normally
pull changes from origin/master (which you set as your
@{upstream}), and push changes to your own personal fork
(e.g., as myfork/topic). You may push to your fork from
multiple machines, requiring you to integrate the changes
from the push destination, rather than upstream. With this
patch, you can just do:
git rebase @{push}
rather than typing out the full name.
The heavy lifting is all done by branch_get_push; here we
just wire it up to the "@{push}" syntax.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21 12:45:47 +08:00
|
|
|
static inline int push_mark(const char *string, int len)
|
|
|
|
{
|
|
|
|
const char *suffix[] = { "@{push}" };
|
|
|
|
return at_mark(string, len, suffix, ARRAY_SIZE(suffix));
|
|
|
|
}
|
|
|
|
|
2012-07-03 00:46:50 +08:00
|
|
|
static int get_sha1_1(const char *name, int len, unsigned char *sha1, unsigned lookup_flags);
|
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:31:57 +08:00
|
|
|
static int interpret_nth_prior_checkout(const char *name, int namelen, struct strbuf *buf);
|
2009-01-18 00:09:55 +08:00
|
|
|
|
2014-09-19 11:45:37 +08:00
|
|
|
static int get_sha1_basic(const char *str, int len, unsigned char *sha1,
|
|
|
|
unsigned int flags)
|
2007-01-19 17:15:15 +08:00
|
|
|
{
|
2010-08-24 12:52:43 +08:00
|
|
|
static const char *warn_msg = "refname '%.*s' is ambiguous.";
|
2013-05-29 20:12:42 +08:00
|
|
|
static const char *object_name_msg = N_(
|
|
|
|
"Git normally never creates a ref that ends with 40 hex characters\n"
|
|
|
|
"because it will be ignored when you just specify 40-hex. These refs\n"
|
|
|
|
"may be created by mistake. For example,\n"
|
|
|
|
"\n"
|
|
|
|
" git checkout -b $br $(git rev-parse ...)\n"
|
|
|
|
"\n"
|
|
|
|
"where \"$br\" is somehow empty and a 40-hex ref is created. Please\n"
|
|
|
|
"examine these refs and maybe delete them. Turn this message off by\n"
|
2013-08-01 04:23:31 +08:00
|
|
|
"running \"git config advice.objectNameWarning false\"");
|
2013-05-29 20:12:42 +08:00
|
|
|
unsigned char tmp_sha1[20];
|
2006-09-12 11:17:35 +08:00
|
|
|
char *real_ref = NULL;
|
2006-10-06 14:16:15 +08:00
|
|
|
int refs_found = 0;
|
2013-05-08 05:55:10 +08:00
|
|
|
int at, reflog_len, nth_prior = 0;
|
2005-08-04 13:15:49 +08:00
|
|
|
|
2013-05-29 20:12:42 +08:00
|
|
|
if (len == 40 && !get_sha1_hex(str, sha1)) {
|
2014-01-07 11:32:01 +08:00
|
|
|
if (warn_ambiguous_refs && warn_on_object_refname_ambiguity) {
|
cat-file: disable object/refname ambiguity check for batch mode
A common use of "cat-file --batch-check" is to feed a list
of objects from "rev-list --objects" or a similar command.
In this instance, all of our input objects are 40-byte sha1
ids. However, cat-file has always allowed arbitrary revision
specifiers, and feeds the result to get_sha1().
Fortunately, get_sha1() recognizes a 40-byte sha1 before
doing any hard work trying to look up refs, meaning this
scenario should end up spending very little time converting
the input into an object sha1. However, since 798c35f
(get_sha1: warn about full or short object names that look
like refs, 2013-05-29), when we encounter this case, we
spend the extra effort to do a refname lookup anyway, just
to print a warning. This is further exacerbated by ca91993
(get_packed_ref_cache: reload packed-refs file when it
changes, 2013-06-20), which makes individual ref lookup more
expensive by requiring a stat() of the packed-refs file for
each missing ref.
With no patches, this is the time it takes to run:
$ git rev-list --objects --all >objects
$ time git cat-file --batch-check='%(objectname)' <objects
on the linux.git repository:
real 1m13.494s
user 0m25.924s
sys 0m47.532s
If we revert ca91993, the packed-refs up-to-date check, it
gets a little better:
real 0m54.697s
user 0m21.692s
sys 0m32.916s
but we are still spending quite a bit of time on ref lookup
(and we would not want to revert that patch, anyway, which
has correctness issues). If we revert 798c35f, disabling
the warning entirely, we get a much more reasonable time:
real 0m7.452s
user 0m6.836s
sys 0m0.608s
This patch does the moral equivalent of this final case (and
gets similar speedups). We introduce a global flag that
callers of get_sha1() can use to avoid paying the price for
the warning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12 14:20:05 +08:00
|
|
|
refs_found = dwim_ref(str, len, tmp_sha1, &real_ref);
|
2014-01-07 11:32:01 +08:00
|
|
|
if (refs_found > 0) {
|
cat-file: disable object/refname ambiguity check for batch mode
A common use of "cat-file --batch-check" is to feed a list
of objects from "rev-list --objects" or a similar command.
In this instance, all of our input objects are 40-byte sha1
ids. However, cat-file has always allowed arbitrary revision
specifiers, and feeds the result to get_sha1().
Fortunately, get_sha1() recognizes a 40-byte sha1 before
doing any hard work trying to look up refs, meaning this
scenario should end up spending very little time converting
the input into an object sha1. However, since 798c35f
(get_sha1: warn about full or short object names that look
like refs, 2013-05-29), when we encounter this case, we
spend the extra effort to do a refname lookup anyway, just
to print a warning. This is further exacerbated by ca91993
(get_packed_ref_cache: reload packed-refs file when it
changes, 2013-06-20), which makes individual ref lookup more
expensive by requiring a stat() of the packed-refs file for
each missing ref.
With no patches, this is the time it takes to run:
$ git rev-list --objects --all >objects
$ time git cat-file --batch-check='%(objectname)' <objects
on the linux.git repository:
real 1m13.494s
user 0m25.924s
sys 0m47.532s
If we revert ca91993, the packed-refs up-to-date check, it
gets a little better:
real 0m54.697s
user 0m21.692s
sys 0m32.916s
but we are still spending quite a bit of time on ref lookup
(and we would not want to revert that patch, anyway, which
has correctness issues). If we revert 798c35f, disabling
the warning entirely, we get a much more reasonable time:
real 0m7.452s
user 0m6.836s
sys 0m0.608s
This patch does the moral equivalent of this final case (and
gets similar speedups). We introduce a global flag that
callers of get_sha1() can use to avoid paying the price for
the warning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12 14:20:05 +08:00
|
|
|
warning(warn_msg, len, str);
|
|
|
|
if (advice_object_name_warning)
|
|
|
|
fprintf(stderr, "%s\n", _(object_name_msg));
|
|
|
|
}
|
|
|
|
free(real_ref);
|
2013-05-29 20:12:42 +08:00
|
|
|
}
|
2005-08-04 13:15:49 +08:00
|
|
|
return 0;
|
2013-05-29 20:12:42 +08:00
|
|
|
}
|
2005-08-04 13:15:49 +08:00
|
|
|
|
2009-01-18 00:09:55 +08:00
|
|
|
/* basic@{time or number or -number} format to query ref-log */
|
2006-10-24 12:15:34 +08:00
|
|
|
reflog_len = at = 0;
|
2009-01-28 07:07:46 +08:00
|
|
|
if (len && str[len-1] == '}') {
|
2013-05-08 05:55:09 +08:00
|
|
|
for (at = len-4; at >= 0; at--) {
|
2006-10-06 14:16:15 +08:00
|
|
|
if (str[at] == '@' && str[at+1] == '{') {
|
2013-05-08 05:55:11 +08:00
|
|
|
if (str[at+2] == '-') {
|
|
|
|
if (at != 0)
|
|
|
|
/* @{-N} not at start */
|
|
|
|
return -1;
|
2013-05-08 05:55:10 +08:00
|
|
|
nth_prior = 1;
|
|
|
|
continue;
|
|
|
|
}
|
sha1_name: implement @{push} shorthand
In a triangular workflow, each branch may have two distinct
points of interest: the @{upstream} that you normally pull
from, and the destination that you normally push to. There
isn't a shorthand for the latter, but it's useful to have.
For instance, you may want to know which commits you haven't
pushed yet:
git log @{push}..
Or as a more complicated example, imagine that you normally
pull changes from origin/master (which you set as your
@{upstream}), and push changes to your own personal fork
(e.g., as myfork/topic). You may push to your fork from
multiple machines, requiring you to integrate the changes
from the push destination, rather than upstream. With this
patch, you can just do:
git rebase @{push}
rather than typing out the full name.
The heavy lifting is all done by branch_get_push; here we
just wire it up to the "@{push}" syntax.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21 12:45:47 +08:00
|
|
|
if (!upstream_mark(str + at, len - at) &&
|
|
|
|
!push_mark(str + at, len - at)) {
|
2009-09-10 23:25:57 +08:00
|
|
|
reflog_len = (len-1) - (at+2);
|
|
|
|
len = at;
|
|
|
|
}
|
2006-10-06 14:16:15 +08:00
|
|
|
break;
|
|
|
|
}
|
2006-05-17 17:56:09 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Be more careful about reference parsing
This does two things:
- we don't allow "." and ".." as components of a refname. Thus get_sha1()
will not accept "./refname" as being the same as "refname" any more.
- git-rev-parse stops doing revision translation after seeing a pathname,
to match the brhaviour of all the tools (once we see a pathname,
everything else will also be parsed as a pathname).
Basically, if you did
git log *
and "gitk" was somewhere in the "*", we don't want to replace the filename
"gitk" with the SHA1 of the branch with the same name.
Of course, if there is any change of ambiguity, you should always use "--"
to make it explicit what are filenames and what are revisions, but this
makes the normal cases sane. The refname rule also means that instead of
the "--", you can do the same thing we're used to doing with filenames
that start with a slash: use "./filename" instead, and now it's a
filename, not an option (and not a revision).
So "git log ./*.c" is now actually a perfectly valid thing to do, even if
the first C-file might have the same name as a branch.
Trivial test:
git-rev-parse gitk ./gitk gitk
should output something like
9843c3074dfbf57117565f6b7c93e3e6812857ee
./gitk
gitk
where the "./gitk" isn't seen as a revision, and the second "gitk" is a
filename simply because we've seen filenames already, and thus stopped
doing revision parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-29 03:41:49 +08:00
|
|
|
/* Accept only unambiguous ref paths. */
|
2007-02-02 06:29:33 +08:00
|
|
|
if (len && ambiguous_path(str, len))
|
Be more careful about reference parsing
This does two things:
- we don't allow "." and ".." as components of a refname. Thus get_sha1()
will not accept "./refname" as being the same as "refname" any more.
- git-rev-parse stops doing revision translation after seeing a pathname,
to match the brhaviour of all the tools (once we see a pathname,
everything else will also be parsed as a pathname).
Basically, if you did
git log *
and "gitk" was somewhere in the "*", we don't want to replace the filename
"gitk" with the SHA1 of the branch with the same name.
Of course, if there is any change of ambiguity, you should always use "--"
to make it explicit what are filenames and what are revisions, but this
makes the normal cases sane. The refname rule also means that instead of
the "--", you can do the same thing we're used to doing with filenames
that start with a slash: use "./filename" instead, and now it's a
filename, not an option (and not a revision).
So "git log ./*.c" is now actually a perfectly valid thing to do, even if
the first C-file might have the same name as a branch.
Trivial test:
git-rev-parse gitk ./gitk gitk
should output something like
9843c3074dfbf57117565f6b7c93e3e6812857ee
./gitk
gitk
where the "./gitk" isn't seen as a revision, and the second "gitk" is a
filename simply because we've seen filenames already, and thus stopped
doing revision parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-29 03:41:49 +08:00
|
|
|
return -1;
|
|
|
|
|
2013-05-08 05:55:10 +08:00
|
|
|
if (nth_prior) {
|
2009-01-18 00:09:55 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2013-05-08 05:55:10 +08:00
|
|
|
int detached;
|
|
|
|
|
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:31:57 +08:00
|
|
|
if (interpret_nth_prior_checkout(str, len, &buf) > 0) {
|
2013-05-08 05:55:10 +08:00
|
|
|
detached = (buf.len == 40 && !get_sha1_hex(buf.buf, sha1));
|
|
|
|
strbuf_release(&buf);
|
|
|
|
if (detached)
|
|
|
|
return 0;
|
2009-01-18 00:09:55 +08:00
|
|
|
}
|
2013-05-08 05:55:10 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!len && reflog_len)
|
2007-02-02 06:29:33 +08:00
|
|
|
/* allow "@{...}" to mean the current branch reflog */
|
|
|
|
refs_found = dwim_ref("HEAD", 4, sha1, &real_ref);
|
2013-05-08 05:55:10 +08:00
|
|
|
else if (reflog_len)
|
2007-02-04 10:49:16 +08:00
|
|
|
refs_found = dwim_log(str, len, sha1, &real_ref);
|
|
|
|
else
|
2007-02-02 06:29:33 +08:00
|
|
|
refs_found = dwim_ref(str, len, sha1, &real_ref);
|
2006-05-17 17:56:09 +08:00
|
|
|
|
|
|
|
if (!refs_found)
|
|
|
|
return -1;
|
|
|
|
|
2014-09-19 11:45:37 +08:00
|
|
|
if (warn_ambiguous_refs && !(flags & GET_SHA1_QUIETLY) &&
|
2013-05-29 20:12:42 +08:00
|
|
|
(refs_found > 1 ||
|
|
|
|
!get_short_sha1(str, len, tmp_sha1, GET_SHA1_QUIETLY)))
|
2010-08-24 12:52:43 +08:00
|
|
|
warning(warn_msg, len, str);
|
2006-05-17 17:56:09 +08:00
|
|
|
|
2006-10-06 14:16:15 +08:00
|
|
|
if (reflog_len) {
|
|
|
|
int nth, i;
|
|
|
|
unsigned long at_time;
|
2007-01-19 17:19:05 +08:00
|
|
|
unsigned long co_time;
|
|
|
|
int co_tz, co_cnt;
|
|
|
|
|
2007-02-02 01:33:23 +08:00
|
|
|
/* Is it asking for N-th entry, or approxidate? */
|
2006-10-06 14:16:15 +08:00
|
|
|
for (i = nth = 0; 0 <= nth && i < reflog_len; i++) {
|
|
|
|
char ch = str[at+2+i];
|
|
|
|
if ('0' <= ch && ch <= '9')
|
|
|
|
nth = nth * 10 + ch - '0';
|
|
|
|
else
|
|
|
|
nth = -1;
|
|
|
|
}
|
2008-08-21 23:40:44 +08:00
|
|
|
if (100000000 <= nth) {
|
|
|
|
at_time = nth;
|
|
|
|
nth = -1;
|
|
|
|
} else if (0 <= nth)
|
2006-10-06 14:16:15 +08:00
|
|
|
at_time = 0;
|
2008-04-30 12:13:58 +08:00
|
|
|
else {
|
2010-01-27 03:58:00 +08:00
|
|
|
int errors = 0;
|
2008-04-30 12:13:58 +08:00
|
|
|
char *tmp = xstrndup(str + at + 2, reflog_len);
|
2010-01-27 03:58:00 +08:00
|
|
|
at_time = approxidate_careful(tmp, &errors);
|
2008-04-30 12:13:58 +08:00
|
|
|
free(tmp);
|
2014-07-24 12:41:11 +08:00
|
|
|
if (errors) {
|
|
|
|
free(real_ref);
|
2010-01-28 02:53:09 +08:00
|
|
|
return -1;
|
2014-07-24 12:41:11 +08:00
|
|
|
}
|
2008-04-30 12:13:58 +08:00
|
|
|
}
|
2014-09-19 11:45:37 +08:00
|
|
|
if (read_ref_at(real_ref, flags, at_time, nth, sha1, NULL,
|
2007-01-19 17:19:05 +08:00
|
|
|
&co_time, &co_tz, &co_cnt)) {
|
2013-05-22 18:39:55 +08:00
|
|
|
if (!len) {
|
2013-12-01 04:55:40 +08:00
|
|
|
if (starts_with(real_ref, "refs/heads/")) {
|
2013-05-22 18:39:55 +08:00
|
|
|
str = real_ref + 11;
|
|
|
|
len = strlen(real_ref + 11);
|
|
|
|
} else {
|
|
|
|
/* detached HEAD */
|
|
|
|
str = "HEAD";
|
|
|
|
len = 4;
|
|
|
|
}
|
|
|
|
}
|
2014-09-19 11:45:37 +08:00
|
|
|
if (at_time) {
|
|
|
|
if (!(flags & GET_SHA1_QUIETLY)) {
|
|
|
|
warning("Log for '%.*s' only goes "
|
|
|
|
"back to %s.", len, str,
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-26 00:55:02 +08:00
|
|
|
show_date(co_time, co_tz, DATE_MODE(RFC2822)));
|
2014-09-19 11:45:37 +08:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (flags & GET_SHA1_QUIETLY) {
|
|
|
|
exit(128);
|
|
|
|
}
|
2010-08-24 12:52:42 +08:00
|
|
|
die("Log for '%.*s' only has %d entries.",
|
|
|
|
len, str, co_cnt);
|
|
|
|
}
|
2007-01-19 17:19:05 +08:00
|
|
|
}
|
2006-05-17 17:56:09 +08:00
|
|
|
}
|
|
|
|
|
2006-09-12 11:17:35 +08:00
|
|
|
free(real_ref);
|
2006-05-17 17:56:09 +08:00
|
|
|
return 0;
|
2005-08-04 13:15:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int get_parent(const char *name, int len,
|
|
|
|
unsigned char *result, int idx)
|
|
|
|
{
|
|
|
|
unsigned char sha1[20];
|
2012-07-03 01:00:40 +08:00
|
|
|
int ret = get_sha1_1(name, len, sha1, GET_SHA1_COMMITTISH);
|
2005-08-04 13:15:49 +08:00
|
|
|
struct commit *commit;
|
|
|
|
struct commit_list *p;
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
commit = lookup_commit_reference(sha1);
|
|
|
|
if (parse_commit(commit))
|
|
|
|
return -1;
|
|
|
|
if (!idx) {
|
2015-11-10 10:22:29 +08:00
|
|
|
hashcpy(result, commit->object.oid.hash);
|
2005-08-04 13:15:49 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
p = commit->parents;
|
|
|
|
while (p) {
|
|
|
|
if (!--idx) {
|
2015-11-10 10:22:29 +08:00
|
|
|
hashcpy(result, p->item->object.oid.hash);
|
2005-08-04 13:15:49 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
p = p->next;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2005-08-21 17:43:54 +08:00
|
|
|
static int get_nth_ancestor(const char *name, int len,
|
|
|
|
unsigned char *result, int generation)
|
|
|
|
{
|
|
|
|
unsigned char sha1[20];
|
2008-03-15 02:49:40 +08:00
|
|
|
struct commit *commit;
|
|
|
|
int ret;
|
|
|
|
|
2012-07-03 01:00:40 +08:00
|
|
|
ret = get_sha1_1(name, len, sha1, GET_SHA1_COMMITTISH);
|
2005-08-21 17:43:54 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2008-03-15 02:49:40 +08:00
|
|
|
commit = lookup_commit_reference(sha1);
|
|
|
|
if (!commit)
|
|
|
|
return -1;
|
2005-08-21 17:43:54 +08:00
|
|
|
|
|
|
|
while (generation--) {
|
2008-03-15 02:49:40 +08:00
|
|
|
if (parse_commit(commit) || !commit->parents)
|
2005-08-21 17:43:54 +08:00
|
|
|
return -1;
|
2008-03-15 02:49:40 +08:00
|
|
|
commit = commit->parents->item;
|
2005-08-21 17:43:54 +08:00
|
|
|
}
|
2015-11-10 10:22:29 +08:00
|
|
|
hashcpy(result, commit->object.oid.hash);
|
2005-08-21 17:43:54 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-12-24 16:51:01 +08:00
|
|
|
struct object *peel_to_type(const char *name, int namelen,
|
|
|
|
struct object *o, enum object_type expected_type)
|
|
|
|
{
|
|
|
|
if (name && !namelen)
|
|
|
|
namelen = strlen(name);
|
|
|
|
while (1) {
|
2015-11-10 10:22:29 +08:00
|
|
|
if (!o || (!o->parsed && !parse_object(o->oid.hash)))
|
2007-12-24 16:51:01 +08:00
|
|
|
return NULL;
|
2013-04-01 06:24:12 +08:00
|
|
|
if (expected_type == OBJ_ANY || o->type == expected_type)
|
2007-12-24 16:51:01 +08:00
|
|
|
return o;
|
|
|
|
if (o->type == OBJ_TAG)
|
|
|
|
o = ((struct tag*) o)->tagged;
|
|
|
|
else if (o->type == OBJ_COMMIT)
|
|
|
|
o = &(((struct commit *) o)->tree->object);
|
|
|
|
else {
|
|
|
|
if (name)
|
|
|
|
error("%.*s: expected %s type, but the object "
|
|
|
|
"dereferences to %s type",
|
|
|
|
namelen, name, typename(expected_type),
|
|
|
|
typename(o->type));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-26 19:59:41 +08:00
|
|
|
static int peel_onion(const char *name, int len, unsigned char *sha1,
|
|
|
|
unsigned lookup_flags)
|
2005-10-14 09:57:40 +08:00
|
|
|
{
|
|
|
|
unsigned char outer[20];
|
|
|
|
const char *sp;
|
Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-15 07:45:13 +08:00
|
|
|
unsigned int expected_type = 0;
|
2005-10-14 09:57:40 +08:00
|
|
|
struct object *o;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* "ref^{type}" dereferences ref repeatedly until you cannot
|
|
|
|
* dereference anymore, or you get an object of given type,
|
|
|
|
* whichever comes first. "ref^{}" means just dereference
|
|
|
|
* tags until you get a non-tag. "ref^0" is a shorthand for
|
|
|
|
* "ref^{commit}". "commit^{tree}" could be used to find the
|
|
|
|
* top-level tree of the given commit.
|
|
|
|
*/
|
|
|
|
if (len < 4 || name[len-1] != '}')
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
for (sp = name + len - 1; name <= sp; sp--) {
|
|
|
|
int ch = *sp;
|
|
|
|
if (ch == '{' && name < sp && sp[-1] == '^')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (sp <= name)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
sp++; /* beginning of type name, or closing brace for empty */
|
2013-12-01 04:55:40 +08:00
|
|
|
if (starts_with(sp, "commit}"))
|
2006-07-12 11:45:31 +08:00
|
|
|
expected_type = OBJ_COMMIT;
|
2013-12-01 04:55:40 +08:00
|
|
|
else if (starts_with(sp, "tag}"))
|
2013-09-04 03:50:16 +08:00
|
|
|
expected_type = OBJ_TAG;
|
2013-12-01 04:55:40 +08:00
|
|
|
else if (starts_with(sp, "tree}"))
|
2006-07-12 11:45:31 +08:00
|
|
|
expected_type = OBJ_TREE;
|
2013-12-01 04:55:40 +08:00
|
|
|
else if (starts_with(sp, "blob}"))
|
2006-07-12 11:45:31 +08:00
|
|
|
expected_type = OBJ_BLOB;
|
2013-12-01 04:55:40 +08:00
|
|
|
else if (starts_with(sp, "object}"))
|
2013-04-01 06:24:12 +08:00
|
|
|
expected_type = OBJ_ANY;
|
2005-10-14 09:57:40 +08:00
|
|
|
else if (sp[0] == '}')
|
2006-07-12 11:45:31 +08:00
|
|
|
expected_type = OBJ_NONE;
|
2010-12-13 11:01:15 +08:00
|
|
|
else if (sp[0] == '/')
|
|
|
|
expected_type = OBJ_COMMIT;
|
2005-10-14 09:57:40 +08:00
|
|
|
else
|
|
|
|
return -1;
|
|
|
|
|
2016-09-26 19:59:41 +08:00
|
|
|
lookup_flags &= ~GET_SHA1_DISAMBIGUATORS;
|
2012-07-03 01:00:40 +08:00
|
|
|
if (expected_type == OBJ_COMMIT)
|
2016-09-26 19:59:41 +08:00
|
|
|
lookup_flags |= GET_SHA1_COMMITTISH;
|
2013-04-01 06:19:52 +08:00
|
|
|
else if (expected_type == OBJ_TREE)
|
2016-09-26 19:59:41 +08:00
|
|
|
lookup_flags |= GET_SHA1_TREEISH;
|
2012-07-03 01:00:40 +08:00
|
|
|
|
|
|
|
if (get_sha1_1(name, sp - name - 2, outer, lookup_flags))
|
2005-10-14 09:57:40 +08:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
o = parse_object(outer);
|
|
|
|
if (!o)
|
|
|
|
return -1;
|
Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-15 07:45:13 +08:00
|
|
|
if (!expected_type) {
|
2005-11-03 07:19:13 +08:00
|
|
|
o = deref_tag(o, name, sp - name - 2);
|
2015-11-10 10:22:29 +08:00
|
|
|
if (!o || (!o->parsed && !parse_object(o->oid.hash)))
|
2005-10-20 13:48:16 +08:00
|
|
|
return -1;
|
2015-11-10 10:22:28 +08:00
|
|
|
hashcpy(sha1, o->oid.hash);
|
2010-12-13 11:01:15 +08:00
|
|
|
return 0;
|
2005-10-14 09:57:40 +08:00
|
|
|
}
|
2010-12-13 11:01:15 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* At this point, the syntax look correct, so
|
|
|
|
* if we do not get the needed object, we should
|
|
|
|
* barf.
|
|
|
|
*/
|
|
|
|
o = peel_to_type(name, len, o, expected_type);
|
|
|
|
if (!o)
|
2007-12-24 16:51:01 +08:00
|
|
|
return -1;
|
2010-12-13 11:01:15 +08:00
|
|
|
|
2015-11-10 10:22:29 +08:00
|
|
|
hashcpy(sha1, o->oid.hash);
|
2010-12-13 11:01:15 +08:00
|
|
|
if (sp[0] == '/') {
|
|
|
|
/* "$commit^{/foo}" */
|
|
|
|
char *prefix;
|
|
|
|
int ret;
|
|
|
|
struct commit_list *list = NULL;
|
|
|
|
|
2007-12-24 16:51:01 +08:00
|
|
|
/*
|
2010-12-15 17:02:54 +08:00
|
|
|
* $commit^{/}. Some regex implementation may reject.
|
|
|
|
* We don't need regex anyway. '' pattern always matches.
|
2005-10-14 09:57:40 +08:00
|
|
|
*/
|
2010-12-15 17:02:54 +08:00
|
|
|
if (sp[1] == '}')
|
2007-12-24 16:51:01 +08:00
|
|
|
return 0;
|
2010-12-15 17:02:54 +08:00
|
|
|
|
2010-12-13 11:01:15 +08:00
|
|
|
prefix = xstrndup(sp + 1, name + len - 1 - (sp + 1));
|
|
|
|
commit_list_insert((struct commit *)o, &list);
|
|
|
|
ret = get_sha1_oneline(prefix, sha1, list);
|
|
|
|
free(prefix);
|
|
|
|
return ret;
|
2005-10-14 09:57:40 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-09-21 07:11:08 +08:00
|
|
|
static int get_describe_name(const char *name, int len, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
const char *cp;
|
2012-06-19 04:45:56 +08:00
|
|
|
unsigned flags = GET_SHA1_QUIETLY | GET_SHA1_COMMIT;
|
2006-09-21 07:11:08 +08:00
|
|
|
|
|
|
|
for (cp = name + len - 1; name + 2 <= cp; cp--) {
|
|
|
|
char ch = *cp;
|
2015-03-10 06:46:54 +08:00
|
|
|
if (!isxdigit(ch)) {
|
2006-09-21 07:11:08 +08:00
|
|
|
/* We must be looking at g in "SOMETHING-g"
|
|
|
|
* for it to be describe output.
|
|
|
|
*/
|
|
|
|
if (ch == 'g' && cp[-1] == '-') {
|
|
|
|
cp++;
|
|
|
|
len -= cp - name;
|
2012-06-19 04:45:56 +08:00
|
|
|
return get_short_sha1(cp, len, sha1, flags);
|
2006-09-21 07:11:08 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2012-07-03 00:46:50 +08:00
|
|
|
static int get_sha1_1(const char *name, int len, unsigned char *sha1, unsigned lookup_flags)
|
2005-08-04 13:15:49 +08:00
|
|
|
{
|
2006-02-03 15:48:36 +08:00
|
|
|
int ret, has_suffix;
|
2005-08-21 17:43:54 +08:00
|
|
|
const char *cp;
|
2005-08-04 13:15:49 +08:00
|
|
|
|
2008-03-15 02:49:40 +08:00
|
|
|
/*
|
|
|
|
* "name~3" is "name^^^", "name~" is "name~1", and "name^" is "name^1".
|
2005-08-21 17:43:54 +08:00
|
|
|
*/
|
2006-02-03 15:48:36 +08:00
|
|
|
has_suffix = 0;
|
2005-08-21 17:43:54 +08:00
|
|
|
for (cp = name + len - 1; name <= cp; cp--) {
|
|
|
|
int ch = *cp;
|
|
|
|
if ('0' <= ch && ch <= '9')
|
|
|
|
continue;
|
2006-02-03 15:48:36 +08:00
|
|
|
if (ch == '~' || ch == '^')
|
|
|
|
has_suffix = ch;
|
2005-08-21 17:43:54 +08:00
|
|
|
break;
|
|
|
|
}
|
2006-02-03 15:48:36 +08:00
|
|
|
|
|
|
|
if (has_suffix) {
|
|
|
|
int num = 0;
|
2005-08-21 17:43:54 +08:00
|
|
|
int len1 = cp - name;
|
|
|
|
cp++;
|
|
|
|
while (cp < name + len)
|
2006-02-03 15:48:36 +08:00
|
|
|
num = num * 10 + *cp++ - '0';
|
2008-03-15 02:49:40 +08:00
|
|
|
if (!num && len1 == len - 1)
|
|
|
|
num = 1;
|
|
|
|
if (has_suffix == '^')
|
2006-02-03 15:48:36 +08:00
|
|
|
return get_parent(name, len1, sha1, num);
|
|
|
|
/* else if (has_suffix == '~') -- goes without saying */
|
|
|
|
return get_nth_ancestor(name, len1, sha1, num);
|
2005-08-21 17:43:54 +08:00
|
|
|
}
|
|
|
|
|
2016-09-26 19:59:41 +08:00
|
|
|
ret = peel_onion(name, len, sha1, lookup_flags);
|
2005-10-14 09:57:40 +08:00
|
|
|
if (!ret)
|
|
|
|
return 0;
|
|
|
|
|
2014-09-19 11:45:37 +08:00
|
|
|
ret = get_sha1_basic(name, len, sha1, lookup_flags);
|
2005-08-04 13:15:49 +08:00
|
|
|
if (!ret)
|
|
|
|
return 0;
|
2006-09-21 07:11:08 +08:00
|
|
|
|
|
|
|
/* It could be describe output that is "SOMETHING-gXXXX" */
|
|
|
|
ret = get_describe_name(name, len, sha1);
|
|
|
|
if (!ret)
|
|
|
|
return 0;
|
|
|
|
|
2012-07-03 01:00:40 +08:00
|
|
|
return get_short_sha1(name, len, sha1, lookup_flags);
|
2005-08-04 13:15:49 +08:00
|
|
|
}
|
|
|
|
|
2010-08-03 05:37:06 +08:00
|
|
|
/*
|
|
|
|
* This interprets names like ':/Initial revision of "git"' by searching
|
|
|
|
* through history and returning the first commit whose message starts
|
2010-08-13 09:32:49 +08:00
|
|
|
* the given regular expression.
|
2010-08-03 05:37:06 +08:00
|
|
|
*
|
object name: introduce '^{/!-<negative pattern>}' notation
To name a commit, you can now use the :/!-<negative pattern> regex
style, and consequentially, say
$ git rev-parse HEAD^{/!-foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo". This is the opposite of the
existing <rev>^{/<pattern>} syntax.
The specific use-case this is intended for is to perform an operation,
excluding the most-recent commits containing a particular marker. For
example, if you tend to make "work in progress" commits, with messages
beginning with "WIP", you work, then it could be useful to diff against
"the most recent commit which was not a WIP commit". That sort of thing
now possible, via commands such as:
$ git diff @^{/!-^WIP}
The leader '/!-', rather than simply '/!', to denote a negative match,
is chosen to leave room for additional modifiers in the future.
Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-31 08:06:01 +08:00
|
|
|
* For negative-matching, prefix the pattern-part with '!-', like: ':/!-WIP'.
|
|
|
|
*
|
|
|
|
* For a literal '!' character at the beginning of a pattern, you have to repeat
|
|
|
|
* that, like: ':/!!foo'
|
|
|
|
*
|
|
|
|
* For future extension, all other sequences beginning with ':/!' are reserved.
|
2010-08-03 05:37:06 +08:00
|
|
|
*/
|
2014-03-25 21:23:26 +08:00
|
|
|
|
|
|
|
/* Remember to update object flag allocation in object.h */
|
2010-08-03 05:37:06 +08:00
|
|
|
#define ONELINE_SEEN (1u<<20)
|
|
|
|
|
2015-05-26 02:39:05 +08:00
|
|
|
static int handle_one_ref(const char *path, const struct object_id *oid,
|
|
|
|
int flag, void *cb_data)
|
2007-02-24 10:08:20 +08:00
|
|
|
{
|
|
|
|
struct commit_list **list = cb_data;
|
2015-05-26 02:39:05 +08:00
|
|
|
struct object *object = parse_object(oid->hash);
|
2007-02-24 10:08:20 +08:00
|
|
|
if (!object)
|
|
|
|
return 0;
|
2008-02-18 15:31:54 +08:00
|
|
|
if (object->type == OBJ_TAG) {
|
2007-02-24 10:08:20 +08:00
|
|
|
object = deref_tag(object, path, strlen(path));
|
2008-02-18 15:31:54 +08:00
|
|
|
if (!object)
|
|
|
|
return 0;
|
|
|
|
}
|
2007-02-24 10:08:20 +08:00
|
|
|
if (object->type != OBJ_COMMIT)
|
|
|
|
return 0;
|
2014-08-22 02:30:29 +08:00
|
|
|
commit_list_insert((struct commit *)object, list);
|
2007-02-24 10:08:20 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-12-13 11:01:14 +08:00
|
|
|
static int get_sha1_oneline(const char *prefix, unsigned char *sha1,
|
|
|
|
struct commit_list *list)
|
2007-02-24 10:08:20 +08:00
|
|
|
{
|
2010-12-13 11:01:14 +08:00
|
|
|
struct commit_list *backup = NULL, *l;
|
2010-12-13 14:19:00 +08:00
|
|
|
int found = 0;
|
object name: introduce '^{/!-<negative pattern>}' notation
To name a commit, you can now use the :/!-<negative pattern> regex
style, and consequentially, say
$ git rev-parse HEAD^{/!-foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo". This is the opposite of the
existing <rev>^{/<pattern>} syntax.
The specific use-case this is intended for is to perform an operation,
excluding the most-recent commits containing a particular marker. For
example, if you tend to make "work in progress" commits, with messages
beginning with "WIP", you work, then it could be useful to diff against
"the most recent commit which was not a WIP commit". That sort of thing
now possible, via commands such as:
$ git diff @^{/!-^WIP}
The leader '/!-', rather than simply '/!', to denote a negative match,
is chosen to leave room for additional modifiers in the future.
Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-31 08:06:01 +08:00
|
|
|
int negative = 0;
|
2010-04-23 23:20:20 +08:00
|
|
|
regex_t regex;
|
2007-02-24 10:08:20 +08:00
|
|
|
|
|
|
|
if (prefix[0] == '!') {
|
|
|
|
prefix++;
|
object name: introduce '^{/!-<negative pattern>}' notation
To name a commit, you can now use the :/!-<negative pattern> regex
style, and consequentially, say
$ git rev-parse HEAD^{/!-foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo". This is the opposite of the
existing <rev>^{/<pattern>} syntax.
The specific use-case this is intended for is to perform an operation,
excluding the most-recent commits containing a particular marker. For
example, if you tend to make "work in progress" commits, with messages
beginning with "WIP", you work, then it could be useful to diff against
"the most recent commit which was not a WIP commit". That sort of thing
now possible, via commands such as:
$ git diff @^{/!-^WIP}
The leader '/!-', rather than simply '/!', to denote a negative match,
is chosen to leave room for additional modifiers in the future.
Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-31 08:06:01 +08:00
|
|
|
|
|
|
|
if (prefix[0] == '-') {
|
|
|
|
prefix++;
|
|
|
|
negative = 1;
|
|
|
|
} else if (prefix[0] != '!') {
|
2016-02-25 05:25:52 +08:00
|
|
|
return -1;
|
object name: introduce '^{/!-<negative pattern>}' notation
To name a commit, you can now use the :/!-<negative pattern> regex
style, and consequentially, say
$ git rev-parse HEAD^{/!-foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo". This is the opposite of the
existing <rev>^{/<pattern>} syntax.
The specific use-case this is intended for is to perform an operation,
excluding the most-recent commits containing a particular marker. For
example, if you tend to make "work in progress" commits, with messages
beginning with "WIP", you work, then it could be useful to diff against
"the most recent commit which was not a WIP commit". That sort of thing
now possible, via commands such as:
$ git diff @^{/!-^WIP}
The leader '/!-', rather than simply '/!', to denote a negative match,
is chosen to leave room for additional modifiers in the future.
Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-31 08:06:01 +08:00
|
|
|
}
|
2007-02-24 10:08:20 +08:00
|
|
|
}
|
2010-04-23 23:20:20 +08:00
|
|
|
|
|
|
|
if (regcomp(®ex, prefix, REG_EXTENDED))
|
2016-02-11 05:19:25 +08:00
|
|
|
return -1;
|
2010-04-23 23:20:20 +08:00
|
|
|
|
2010-12-13 11:01:14 +08:00
|
|
|
for (l = list; l; l = l->next) {
|
|
|
|
l->item->object.flags |= ONELINE_SEEN;
|
2007-02-24 10:08:20 +08:00
|
|
|
commit_list_insert(l->item, &backup);
|
2010-12-13 11:01:14 +08:00
|
|
|
}
|
2007-03-12 02:49:08 +08:00
|
|
|
while (list) {
|
2014-06-11 05:41:02 +08:00
|
|
|
const char *p, *buf;
|
2007-03-13 02:30:38 +08:00
|
|
|
struct commit *commit;
|
2010-12-13 14:19:00 +08:00
|
|
|
int matches;
|
2007-03-12 02:49:08 +08:00
|
|
|
|
|
|
|
commit = pop_most_recent_commit(&list, ONELINE_SEEN);
|
2015-11-10 10:22:29 +08:00
|
|
|
if (!parse_object(commit->object.oid.hash))
|
2008-02-19 04:47:53 +08:00
|
|
|
continue;
|
2014-06-11 05:44:13 +08:00
|
|
|
buf = get_commit_buffer(commit, NULL);
|
2014-06-11 05:41:02 +08:00
|
|
|
p = strstr(buf, "\n\n");
|
object name: introduce '^{/!-<negative pattern>}' notation
To name a commit, you can now use the :/!-<negative pattern> regex
style, and consequentially, say
$ git rev-parse HEAD^{/!-foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo". This is the opposite of the
existing <rev>^{/<pattern>} syntax.
The specific use-case this is intended for is to perform an operation,
excluding the most-recent commits containing a particular marker. For
example, if you tend to make "work in progress" commits, with messages
beginning with "WIP", you work, then it could be useful to diff against
"the most recent commit which was not a WIP commit". That sort of thing
now possible, via commands such as:
$ git diff @^{/!-^WIP}
The leader '/!-', rather than simply '/!', to denote a negative match,
is chosen to leave room for additional modifiers in the future.
Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-31 08:06:01 +08:00
|
|
|
matches = negative ^ (p && !regexec(®ex, p + 2, 0, NULL, 0));
|
2014-06-11 05:41:02 +08:00
|
|
|
unuse_commit_buffer(commit, buf);
|
2010-12-13 14:19:00 +08:00
|
|
|
|
|
|
|
if (matches) {
|
2015-11-10 10:22:29 +08:00
|
|
|
hashcpy(sha1, commit->object.oid.hash);
|
2010-12-13 14:19:00 +08:00
|
|
|
found = 1;
|
2007-02-24 10:08:20 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2010-04-23 23:20:20 +08:00
|
|
|
regfree(®ex);
|
2007-02-24 10:08:20 +08:00
|
|
|
free_commit_list(list);
|
|
|
|
for (l = backup; l; l = l->next)
|
|
|
|
clear_commit_marks(l->item, ONELINE_SEEN);
|
2010-12-13 14:19:00 +08:00
|
|
|
free_commit_list(backup);
|
|
|
|
return found ? 0 : -1;
|
2007-02-24 10:08:20 +08:00
|
|
|
}
|
|
|
|
|
2009-01-18 00:09:53 +08:00
|
|
|
struct grab_nth_branch_switch_cbdata {
|
2013-03-09 05:27:37 +08:00
|
|
|
int remaining;
|
|
|
|
struct strbuf buf;
|
2009-01-18 00:09:53 +08:00
|
|
|
};
|
|
|
|
|
2017-02-22 07:47:32 +08:00
|
|
|
static int grab_nth_branch_switch(struct object_id *ooid, struct object_id *noid,
|
2009-01-18 00:09:53 +08:00
|
|
|
const char *email, unsigned long timestamp, int tz,
|
|
|
|
const char *message, void *cb_data)
|
|
|
|
{
|
|
|
|
struct grab_nth_branch_switch_cbdata *cb = cb_data;
|
2009-01-18 00:09:54 +08:00
|
|
|
const char *match = NULL, *target = NULL;
|
|
|
|
size_t len;
|
|
|
|
|
2014-06-19 03:48:29 +08:00
|
|
|
if (skip_prefix(message, "checkout: moving from ", &match))
|
2009-01-21 16:37:38 +08:00
|
|
|
target = strstr(match, " to ");
|
2009-01-18 00:09:53 +08:00
|
|
|
|
2009-01-20 08:44:08 +08:00
|
|
|
if (!match || !target)
|
2009-01-18 00:09:53 +08:00
|
|
|
return 0;
|
2013-03-09 05:27:37 +08:00
|
|
|
if (--(cb->remaining) == 0) {
|
|
|
|
len = target - match;
|
|
|
|
strbuf_reset(&cb->buf);
|
|
|
|
strbuf_add(&cb->buf, match, len);
|
|
|
|
return 1; /* we are done */
|
|
|
|
}
|
2009-01-18 00:09:53 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2010-01-20 15:17:11 +08:00
|
|
|
* Parse @{-N} syntax, return the number of characters parsed
|
|
|
|
* if successful; otherwise signal an error with negative value.
|
2009-01-18 00:09:53 +08:00
|
|
|
*/
|
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:31:57 +08:00
|
|
|
static int interpret_nth_prior_checkout(const char *name, int namelen,
|
|
|
|
struct strbuf *buf)
|
2009-01-18 00:09:53 +08:00
|
|
|
{
|
2009-01-19 16:04:25 +08:00
|
|
|
long nth;
|
2013-03-09 05:27:37 +08:00
|
|
|
int retval;
|
2009-01-18 00:09:53 +08:00
|
|
|
struct grab_nth_branch_switch_cbdata cb;
|
2009-01-18 00:09:54 +08:00
|
|
|
const char *brace;
|
|
|
|
char *num_end;
|
2009-01-18 00:09:53 +08:00
|
|
|
|
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:31:57 +08:00
|
|
|
if (namelen < 4)
|
|
|
|
return -1;
|
2009-01-18 00:09:53 +08:00
|
|
|
if (name[0] != '@' || name[1] != '{' || name[2] != '-')
|
|
|
|
return -1;
|
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:31:57 +08:00
|
|
|
brace = memchr(name, '}', namelen);
|
2009-01-18 00:09:54 +08:00
|
|
|
if (!brace)
|
|
|
|
return -1;
|
2013-03-09 05:27:37 +08:00
|
|
|
nth = strtol(name + 3, &num_end, 10);
|
2009-01-18 00:09:54 +08:00
|
|
|
if (num_end != brace)
|
2009-01-18 00:09:53 +08:00
|
|
|
return -1;
|
2009-01-19 16:04:25 +08:00
|
|
|
if (nth <= 0)
|
|
|
|
return -1;
|
2013-03-09 05:27:37 +08:00
|
|
|
cb.remaining = nth;
|
|
|
|
strbuf_init(&cb.buf, 20);
|
|
|
|
|
2009-01-20 13:58:31 +08:00
|
|
|
retval = 0;
|
2013-03-09 05:27:37 +08:00
|
|
|
if (0 < for_each_reflog_ent_reverse("HEAD", grab_nth_branch_switch, &cb)) {
|
|
|
|
strbuf_reset(buf);
|
2014-07-10 16:52:21 +08:00
|
|
|
strbuf_addbuf(buf, &cb.buf);
|
2013-03-09 05:27:37 +08:00
|
|
|
retval = brace - name + 1;
|
|
|
|
}
|
2009-01-18 00:09:54 +08:00
|
|
|
|
2013-03-09 05:27:37 +08:00
|
|
|
strbuf_release(&cb.buf);
|
2009-01-20 13:58:31 +08:00
|
|
|
return retval;
|
2009-01-18 00:09:53 +08:00
|
|
|
}
|
|
|
|
|
2016-09-06 04:08:07 +08:00
|
|
|
int get_oid_mb(const char *name, struct object_id *oid)
|
2009-10-19 03:34:56 +08:00
|
|
|
{
|
|
|
|
struct commit *one, *two;
|
|
|
|
struct commit_list *mbs;
|
2016-09-06 04:08:07 +08:00
|
|
|
struct object_id oid_tmp;
|
2009-10-19 03:34:56 +08:00
|
|
|
const char *dots;
|
|
|
|
int st;
|
|
|
|
|
|
|
|
dots = strstr(name, "...");
|
|
|
|
if (!dots)
|
2016-09-06 04:08:07 +08:00
|
|
|
return get_oid(name, oid);
|
2009-10-19 03:34:56 +08:00
|
|
|
if (dots == name)
|
2016-09-06 04:08:07 +08:00
|
|
|
st = get_oid("HEAD", &oid_tmp);
|
2009-10-19 03:34:56 +08:00
|
|
|
else {
|
|
|
|
struct strbuf sb;
|
|
|
|
strbuf_init(&sb, dots - name);
|
|
|
|
strbuf_add(&sb, name, dots - name);
|
2016-09-06 04:08:07 +08:00
|
|
|
st = get_sha1_committish(sb.buf, oid_tmp.hash);
|
2009-10-19 03:34:56 +08:00
|
|
|
strbuf_release(&sb);
|
|
|
|
}
|
|
|
|
if (st)
|
|
|
|
return st;
|
2016-09-06 04:08:07 +08:00
|
|
|
one = lookup_commit_reference_gently(oid_tmp.hash, 0);
|
2009-10-19 03:34:56 +08:00
|
|
|
if (!one)
|
|
|
|
return -1;
|
|
|
|
|
2016-09-06 04:08:07 +08:00
|
|
|
if (get_sha1_committish(dots[3] ? (dots + 3) : "HEAD", oid_tmp.hash))
|
2009-10-19 03:34:56 +08:00
|
|
|
return -1;
|
2016-09-06 04:08:07 +08:00
|
|
|
two = lookup_commit_reference_gently(oid_tmp.hash, 0);
|
2009-10-19 03:34:56 +08:00
|
|
|
if (!two)
|
|
|
|
return -1;
|
2014-10-31 03:20:44 +08:00
|
|
|
mbs = get_merge_bases(one, two);
|
2009-10-19 03:34:56 +08:00
|
|
|
if (!mbs || mbs->next)
|
|
|
|
st = -1;
|
|
|
|
else {
|
|
|
|
st = 0;
|
2016-09-06 04:08:07 +08:00
|
|
|
oidcpy(oid, &mbs->item->object.oid);
|
2009-10-19 03:34:56 +08:00
|
|
|
}
|
|
|
|
free_commit_list(mbs);
|
|
|
|
return st;
|
|
|
|
}
|
|
|
|
|
Add new @ shortcut for HEAD
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-02 14:34:30 +08:00
|
|
|
/* parse @something syntax, when 'something' is not {.*} */
|
|
|
|
static int interpret_empty_at(const char *name, int namelen, int len, struct strbuf *buf)
|
|
|
|
{
|
|
|
|
const char *next;
|
|
|
|
|
|
|
|
if (len || name[1] == '{')
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
/* make sure it's a single @, or @@{.*}, not @foo */
|
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:31:57 +08:00
|
|
|
next = memchr(name + len + 1, '@', namelen - len - 1);
|
Add new @ shortcut for HEAD
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-02 14:34:30 +08:00
|
|
|
if (next && next[1] != '{')
|
|
|
|
return -1;
|
|
|
|
if (!next)
|
|
|
|
next = name + namelen;
|
|
|
|
if (next != name + 1)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
strbuf_reset(buf);
|
|
|
|
strbuf_add(buf, "HEAD", 4);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
static int reinterpret(const char *name, int namelen, int len,
|
|
|
|
struct strbuf *buf, unsigned allowed)
|
2013-05-08 06:04:30 +08:00
|
|
|
{
|
|
|
|
/* we have extra data, which might need further processing */
|
|
|
|
struct strbuf tmp = STRBUF_INIT;
|
|
|
|
int used = buf->len;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
strbuf_add(buf, name + len, namelen - len);
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
ret = interpret_branch_name(buf->buf, buf->len, &tmp, allowed);
|
2013-05-08 06:04:30 +08:00
|
|
|
/* that data was not interpreted, remove our cruft */
|
|
|
|
if (ret < 0) {
|
|
|
|
strbuf_setlen(buf, used);
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
strbuf_reset(buf);
|
|
|
|
strbuf_addbuf(buf, &tmp);
|
|
|
|
strbuf_release(&tmp);
|
|
|
|
/* tweak for size of {-N} versus expanded ref name */
|
|
|
|
return ret - used + len;
|
|
|
|
}
|
|
|
|
|
2014-01-15 16:26:33 +08:00
|
|
|
static void set_shortened_ref(struct strbuf *buf, const char *ref)
|
|
|
|
{
|
|
|
|
char *s = shorten_unambiguous_ref(ref, 0);
|
|
|
|
strbuf_reset(buf);
|
|
|
|
strbuf_addstr(buf, s);
|
|
|
|
free(s);
|
|
|
|
}
|
|
|
|
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
static int branch_interpret_allowed(const char *refname, unsigned allowed)
|
|
|
|
{
|
|
|
|
if (!allowed)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
if ((allowed & INTERPRET_BRANCH_LOCAL) &&
|
|
|
|
starts_with(refname, "refs/heads/"))
|
|
|
|
return 1;
|
|
|
|
if ((allowed & INTERPRET_BRANCH_REMOTE) &&
|
|
|
|
starts_with(refname, "refs/remotes/"))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-05-21 12:45:43 +08:00
|
|
|
static int interpret_branch_mark(const char *name, int namelen,
|
|
|
|
int at, struct strbuf *buf,
|
|
|
|
int (*get_mark)(const char *, int),
|
|
|
|
const char *(*get_data)(struct branch *,
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
struct strbuf *),
|
|
|
|
unsigned allowed)
|
2014-01-15 16:26:33 +08:00
|
|
|
{
|
|
|
|
int len;
|
2015-05-21 12:45:43 +08:00
|
|
|
struct branch *branch;
|
|
|
|
struct strbuf err = STRBUF_INIT;
|
|
|
|
const char *value;
|
2014-01-15 16:26:33 +08:00
|
|
|
|
2015-05-21 12:45:43 +08:00
|
|
|
len = get_mark(name + at, namelen - at);
|
2014-01-15 16:26:33 +08:00
|
|
|
if (!len)
|
|
|
|
return -1;
|
|
|
|
|
interpret_branch_name: avoid @{upstream} past colon
get_sha1() cannot currently parse a valid object name like
"HEAD:@{upstream}" (assuming that such an oddly named file
exists in the HEAD commit). It takes two passes to parse the
string:
1. It first considers the whole thing as a ref, which
results in looking for the upstream of "HEAD:".
2. It finds the colon, parses "HEAD" as a tree-ish, and then
finds the path "@{upstream}" in the tree.
For a path that looks like a normal reflog (e.g.,
"HEAD:@{yesterday}"), the first pass is a no-op. We try to
dwim_ref("HEAD:"), that returns zero refs, and we proceed
with colon-parsing.
For "HEAD:@{upstream}", though, the first pass ends up in
interpret_upstream_mark, which tries to find the branch
"HEAD:". When it sees that the branch does not exist, it
actually dies rather than returning an error to the caller.
As a result, we never make it to the second pass.
One obvious way of fixing this would be to teach
interpret_upstream_mark to simply report "no, this isn't an
upstream" in such a case. However, that would make the
error-reporting for legitimate upstream cases significantly
worse. Something like "bogus@{upstream}" would simply report
"unknown revision: bogus@{upstream}", while the current code
diagnoses a wide variety of possible misconfigurations (no
such branch, branch exists but does not have upstream, etc).
However, we can take advantage of the fact that a branch
name cannot contain a colon. Therefore even if we find an
upstream mark, any prefix with a colon must mean that
the upstream mark we found is actually a pathname, and
should be disregarded completely. This patch implements that
logic.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:37:23 +08:00
|
|
|
if (memchr(name, ':', at))
|
|
|
|
return -1;
|
|
|
|
|
2015-05-21 12:45:43 +08:00
|
|
|
if (at) {
|
|
|
|
char *name_str = xmemdupz(name, at);
|
|
|
|
branch = branch_get(name_str);
|
|
|
|
free(name_str);
|
|
|
|
} else
|
|
|
|
branch = branch_get(NULL);
|
|
|
|
|
|
|
|
value = get_data(branch, &err);
|
|
|
|
if (!value)
|
|
|
|
die("%s", err.buf);
|
|
|
|
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
if (!branch_interpret_allowed(value, allowed))
|
|
|
|
return -1;
|
|
|
|
|
2015-05-21 12:45:43 +08:00
|
|
|
set_shortened_ref(buf, value);
|
2014-01-15 16:26:33 +08:00
|
|
|
return len + at;
|
|
|
|
}
|
|
|
|
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
int interpret_branch_name(const char *name, int namelen, struct strbuf *buf,
|
|
|
|
unsigned allowed)
|
2010-01-20 15:17:11 +08:00
|
|
|
{
|
2014-01-15 16:27:32 +08:00
|
|
|
char *at;
|
interpret_branch_name: find all possible @-marks
When we parse a string like "foo@{upstream}", we look for
the first "@"-sign, and check to see if it is an upstream
mark. However, since branch names can contain an @, we may
also see "@foo@{upstream}". In this case, we check only the
first @, and ignore the second. As a result, we do not find
the upstream.
We can solve this by iterating through all @-marks in the
string, and seeing if any is a legitimate upstream or
empty-at mark.
Another strategy would be to parse from the right-hand side
of the string. However, that does not work for the
"empty_at" case, which allows "@@{upstream}". We need to
find the left-most one in this case (and we then recurse as
"HEAD@{upstream}").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:40:46 +08:00
|
|
|
const char *start;
|
2017-02-27 17:25:40 +08:00
|
|
|
int len;
|
2010-01-20 15:17:11 +08:00
|
|
|
|
2013-09-02 14:34:29 +08:00
|
|
|
if (!namelen)
|
|
|
|
namelen = strlen(name);
|
|
|
|
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
if (!allowed || (allowed & INTERPRET_BRANCH_LOCAL)) {
|
|
|
|
len = interpret_nth_prior_checkout(name, namelen, buf);
|
|
|
|
if (!len) {
|
|
|
|
return len; /* syntax Ok, not enough switches */
|
|
|
|
} else if (len > 0) {
|
|
|
|
if (len == namelen)
|
|
|
|
return len; /* consumed all */
|
|
|
|
else
|
|
|
|
return reinterpret(name, namelen, len, buf, allowed);
|
|
|
|
}
|
2010-01-28 17:52:22 +08:00
|
|
|
}
|
|
|
|
|
interpret_branch_name: find all possible @-marks
When we parse a string like "foo@{upstream}", we look for
the first "@"-sign, and check to see if it is an upstream
mark. However, since branch names can contain an @, we may
also see "@foo@{upstream}". In this case, we check only the
first @, and ignore the second. As a result, we do not find
the upstream.
We can solve this by iterating through all @-marks in the
string, and seeing if any is a legitimate upstream or
empty-at mark.
Another strategy would be to parse from the right-hand side
of the string. However, that does not work for the
"empty_at" case, which allows "@@{upstream}". We need to
find the left-most one in this case (and we then recurse as
"HEAD@{upstream}").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:40:46 +08:00
|
|
|
for (start = name;
|
|
|
|
(at = memchr(start, '@', namelen - (start - name)));
|
|
|
|
start = at + 1) {
|
Add new @ shortcut for HEAD
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-02 14:34:30 +08:00
|
|
|
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
if (!allowed || (allowed & INTERPRET_BRANCH_HEAD)) {
|
|
|
|
len = interpret_empty_at(name, namelen, at - name, buf);
|
|
|
|
if (len > 0)
|
|
|
|
return reinterpret(name, namelen, len, buf,
|
|
|
|
allowed);
|
|
|
|
}
|
Add new @ shortcut for HEAD
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-02 14:34:30 +08:00
|
|
|
|
2015-05-21 12:45:43 +08:00
|
|
|
len = interpret_branch_mark(name, namelen, at - name, buf,
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
upstream_mark, branch_get_upstream,
|
|
|
|
allowed);
|
interpret_branch_name: find all possible @-marks
When we parse a string like "foo@{upstream}", we look for
the first "@"-sign, and check to see if it is an upstream
mark. However, since branch names can contain an @, we may
also see "@foo@{upstream}". In this case, we check only the
first @, and ignore the second. As a result, we do not find
the upstream.
We can solve this by iterating through all @-marks in the
string, and seeing if any is a legitimate upstream or
empty-at mark.
Another strategy would be to parse from the right-hand side
of the string. However, that does not work for the
"empty_at" case, which allows "@@{upstream}". We need to
find the left-most one in this case (and we then recurse as
"HEAD@{upstream}").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:40:46 +08:00
|
|
|
if (len > 0)
|
|
|
|
return len;
|
sha1_name: implement @{push} shorthand
In a triangular workflow, each branch may have two distinct
points of interest: the @{upstream} that you normally pull
from, and the destination that you normally push to. There
isn't a shorthand for the latter, but it's useful to have.
For instance, you may want to know which commits you haven't
pushed yet:
git log @{push}..
Or as a more complicated example, imagine that you normally
pull changes from origin/master (which you set as your
@{upstream}), and push changes to your own personal fork
(e.g., as myfork/topic). You may push to your fork from
multiple machines, requiring you to integrate the changes
from the push destination, rather than upstream. With this
patch, you can just do:
git rebase @{push}
rather than typing out the full name.
The heavy lifting is all done by branch_get_push; here we
just wire it up to the "@{push}" syntax.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21 12:45:47 +08:00
|
|
|
|
|
|
|
len = interpret_branch_mark(name, namelen, at - name, buf,
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
push_mark, branch_get_push,
|
|
|
|
allowed);
|
interpret_branch_name: find all possible @-marks
When we parse a string like "foo@{upstream}", we look for
the first "@"-sign, and check to see if it is an upstream
mark. However, since branch names can contain an @, we may
also see "@foo@{upstream}". In this case, we check only the
first @, and ignore the second. As a result, we do not find
the upstream.
We can solve this by iterating through all @-marks in the
string, and seeing if any is a legitimate upstream or
empty-at mark.
Another strategy would be to parse from the right-hand side
of the string. However, that does not work for the
"empty_at" case, which allows "@@{upstream}". We need to
find the left-most one in this case (and we then recurse as
"HEAD@{upstream}").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:40:46 +08:00
|
|
|
if (len > 0)
|
|
|
|
return len;
|
2012-04-14 15:54:33 +08:00
|
|
|
}
|
Add new @ shortcut for HEAD
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-02 14:34:30 +08:00
|
|
|
|
2014-01-15 16:26:33 +08:00
|
|
|
return -1;
|
2010-01-20 15:17:11 +08:00
|
|
|
}
|
|
|
|
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
void strbuf_branchname(struct strbuf *sb, const char *name, unsigned allowed)
|
2010-11-06 19:46:52 +08:00
|
|
|
{
|
|
|
|
int len = strlen(name);
|
interpret_branch_name: allow callers to restrict expansions
The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").
This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).
Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").
However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).
The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.
We can break the callers down into two groups:
1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().
2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02 16:23:01 +08:00
|
|
|
int used = interpret_branch_name(name, len, sb, allowed);
|
2013-05-16 05:32:30 +08:00
|
|
|
|
|
|
|
if (used < 0)
|
|
|
|
used = 0;
|
|
|
|
strbuf_add(sb, name + used, len - used);
|
2010-11-06 19:46:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int strbuf_check_branch_ref(struct strbuf *sb, const char *name)
|
|
|
|
{
|
2017-03-02 16:23:14 +08:00
|
|
|
strbuf_branchname(sb, name, INTERPRET_BRANCH_LOCAL);
|
2010-11-06 19:46:52 +08:00
|
|
|
if (name[0] == '-')
|
2011-09-16 05:10:25 +08:00
|
|
|
return -1;
|
2010-11-06 19:46:52 +08:00
|
|
|
strbuf_splice(sb, 0, 0, "refs/heads/", 11);
|
2011-09-16 05:10:25 +08:00
|
|
|
return check_refname_format(sb->buf, 0);
|
2010-11-06 19:46:52 +08:00
|
|
|
}
|
|
|
|
|
2005-08-04 13:15:49 +08:00
|
|
|
/*
|
|
|
|
* This is like "get_sha1_basic()", except it allows "sha1 expressions",
|
|
|
|
* notably "xyz^" for "parent of xyz"
|
|
|
|
*/
|
|
|
|
int get_sha1(const char *name, unsigned char *sha1)
|
|
|
|
{
|
2010-06-10 01:02:06 +08:00
|
|
|
struct object_context unused;
|
2012-07-03 01:32:11 +08:00
|
|
|
return get_sha1_with_context(name, 0, sha1, &unused);
|
2007-04-24 04:55:05 +08:00
|
|
|
}
|
|
|
|
|
2016-04-18 07:10:36 +08:00
|
|
|
/*
|
|
|
|
* This is like "get_sha1()", but for struct object_id.
|
|
|
|
*/
|
|
|
|
int get_oid(const char *name, struct object_id *oid)
|
|
|
|
{
|
|
|
|
return get_sha1(name, oid->hash);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-07-03 03:04:52 +08:00
|
|
|
/*
|
2013-09-05 03:04:31 +08:00
|
|
|
* Many callers know that the user meant to name a commit-ish by
|
2012-07-03 03:04:52 +08:00
|
|
|
* syntactical positions where the object name appears. Calling this
|
|
|
|
* function allows the machinery to disambiguate shorter-than-unique
|
2013-09-05 03:04:31 +08:00
|
|
|
* abbreviated object names between commit-ish and others.
|
2012-07-03 03:04:52 +08:00
|
|
|
*
|
|
|
|
* Note that this does NOT error out when the named object is not a
|
2013-09-05 03:04:31 +08:00
|
|
|
* commit-ish. It is merely to give a hint to the disambiguation
|
2012-07-03 03:04:52 +08:00
|
|
|
* machinery.
|
|
|
|
*/
|
|
|
|
int get_sha1_committish(const char *name, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
struct object_context unused;
|
|
|
|
return get_sha1_with_context(name, GET_SHA1_COMMITTISH,
|
|
|
|
sha1, &unused);
|
|
|
|
}
|
|
|
|
|
2012-07-03 14:35:05 +08:00
|
|
|
int get_sha1_treeish(const char *name, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
struct object_context unused;
|
|
|
|
return get_sha1_with_context(name, GET_SHA1_TREEISH,
|
|
|
|
sha1, &unused);
|
|
|
|
}
|
|
|
|
|
|
|
|
int get_sha1_commit(const char *name, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
struct object_context unused;
|
|
|
|
return get_sha1_with_context(name, GET_SHA1_COMMIT,
|
|
|
|
sha1, &unused);
|
|
|
|
}
|
|
|
|
|
|
|
|
int get_sha1_tree(const char *name, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
struct object_context unused;
|
|
|
|
return get_sha1_with_context(name, GET_SHA1_TREE,
|
|
|
|
sha1, &unused);
|
|
|
|
}
|
|
|
|
|
|
|
|
int get_sha1_blob(const char *name, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
struct object_context unused;
|
|
|
|
return get_sha1_with_context(name, GET_SHA1_BLOB,
|
|
|
|
sha1, &unused);
|
2007-04-24 04:55:05 +08:00
|
|
|
}
|
|
|
|
|
2009-12-07 18:10:50 +08:00
|
|
|
/* Must be called only when object_name:filename doesn't exist. */
|
|
|
|
static void diagnose_invalid_sha1_path(const char *prefix,
|
|
|
|
const char *filename,
|
|
|
|
const unsigned char *tree_sha1,
|
2013-03-17 02:29:31 +08:00
|
|
|
const char *object_name,
|
|
|
|
int object_name_len)
|
2009-12-07 18:10:50 +08:00
|
|
|
{
|
|
|
|
unsigned char sha1[20];
|
|
|
|
unsigned mode;
|
|
|
|
|
|
|
|
if (!prefix)
|
|
|
|
prefix = "";
|
|
|
|
|
2015-05-20 05:44:23 +08:00
|
|
|
if (file_exists(filename))
|
2013-03-17 02:29:31 +08:00
|
|
|
die("Path '%s' exists on disk, but not in '%.*s'.",
|
|
|
|
filename, object_name_len, object_name);
|
2009-12-07 18:10:50 +08:00
|
|
|
if (errno == ENOENT || errno == ENOTDIR) {
|
2014-06-20 05:26:56 +08:00
|
|
|
char *fullname = xstrfmt("%s%s", prefix, filename);
|
2009-12-07 18:10:50 +08:00
|
|
|
|
|
|
|
if (!get_tree_entry(tree_sha1, fullname,
|
|
|
|
sha1, &mode)) {
|
|
|
|
die("Path '%s' exists, but not '%s'.\n"
|
2013-03-17 02:29:31 +08:00
|
|
|
"Did you mean '%.*s:%s' aka '%.*s:./%s'?",
|
2009-12-07 18:10:50 +08:00
|
|
|
fullname,
|
|
|
|
filename,
|
2013-03-17 02:29:31 +08:00
|
|
|
object_name_len, object_name,
|
2011-03-31 17:17:34 +08:00
|
|
|
fullname,
|
2013-03-17 02:29:31 +08:00
|
|
|
object_name_len, object_name,
|
2011-03-31 17:17:34 +08:00
|
|
|
filename);
|
2009-12-07 18:10:50 +08:00
|
|
|
}
|
2013-03-17 02:29:31 +08:00
|
|
|
die("Path '%s' does not exist in '%.*s'",
|
|
|
|
filename, object_name_len, object_name);
|
2009-12-07 18:10:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Must be called only when :stage:filename doesn't exist. */
|
|
|
|
static void diagnose_invalid_index_path(int stage,
|
|
|
|
const char *prefix,
|
|
|
|
const char *filename)
|
|
|
|
{
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 23:29:00 +08:00
|
|
|
const struct cache_entry *ce;
|
2009-12-07 18:10:50 +08:00
|
|
|
int pos;
|
|
|
|
unsigned namelen = strlen(filename);
|
2015-09-25 05:07:52 +08:00
|
|
|
struct strbuf fullname = STRBUF_INIT;
|
2009-12-07 18:10:50 +08:00
|
|
|
|
|
|
|
if (!prefix)
|
|
|
|
prefix = "";
|
|
|
|
|
|
|
|
/* Wrong stage number? */
|
|
|
|
pos = cache_name_pos(filename, namelen);
|
|
|
|
if (pos < 0)
|
|
|
|
pos = -pos - 1;
|
2010-02-28 23:49:15 +08:00
|
|
|
if (pos < active_nr) {
|
|
|
|
ce = active_cache[pos];
|
|
|
|
if (ce_namelen(ce) == namelen &&
|
|
|
|
!memcmp(ce->name, filename, namelen))
|
|
|
|
die("Path '%s' is in the index, but not at stage %d.\n"
|
|
|
|
"Did you mean ':%d:%s'?",
|
|
|
|
filename, stage,
|
|
|
|
ce_stage(ce), filename);
|
|
|
|
}
|
2009-12-07 18:10:50 +08:00
|
|
|
|
|
|
|
/* Confusion between relative and absolute filenames? */
|
2015-09-25 05:07:52 +08:00
|
|
|
strbuf_addstr(&fullname, prefix);
|
|
|
|
strbuf_addstr(&fullname, filename);
|
|
|
|
pos = cache_name_pos(fullname.buf, fullname.len);
|
2009-12-07 18:10:50 +08:00
|
|
|
if (pos < 0)
|
|
|
|
pos = -pos - 1;
|
2010-02-28 23:49:15 +08:00
|
|
|
if (pos < active_nr) {
|
|
|
|
ce = active_cache[pos];
|
2015-09-25 05:07:52 +08:00
|
|
|
if (ce_namelen(ce) == fullname.len &&
|
|
|
|
!memcmp(ce->name, fullname.buf, fullname.len))
|
2010-02-28 23:49:15 +08:00
|
|
|
die("Path '%s' is in the index, but not '%s'.\n"
|
2011-03-31 17:17:34 +08:00
|
|
|
"Did you mean ':%d:%s' aka ':%d:./%s'?",
|
2015-09-25 05:07:52 +08:00
|
|
|
fullname.buf, filename,
|
|
|
|
ce_stage(ce), fullname.buf,
|
2011-03-31 17:17:34 +08:00
|
|
|
ce_stage(ce), filename);
|
2010-02-28 23:49:15 +08:00
|
|
|
}
|
2009-12-07 18:10:50 +08:00
|
|
|
|
2015-05-20 05:44:23 +08:00
|
|
|
if (file_exists(filename))
|
2009-12-07 18:10:50 +08:00
|
|
|
die("Path '%s' exists on disk, but not in the index.", filename);
|
|
|
|
if (errno == ENOENT || errno == ENOTDIR)
|
|
|
|
die("Path '%s' does not exist (neither on disk nor in the index).",
|
|
|
|
filename);
|
|
|
|
|
2015-09-25 05:07:52 +08:00
|
|
|
strbuf_release(&fullname);
|
2009-12-07 18:10:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-11-28 11:37:32 +08:00
|
|
|
static char *resolve_relative_path(const char *rel)
|
|
|
|
{
|
2013-12-01 04:55:40 +08:00
|
|
|
if (!starts_with(rel, "./") && !starts_with(rel, "../"))
|
2010-11-28 11:37:32 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (!is_inside_work_tree())
|
|
|
|
die("relative path syntax can't be used outside working tree.");
|
|
|
|
|
|
|
|
/* die() inside prefix_path() if resolved path is outside worktree */
|
|
|
|
return prefix_path(startup_info->prefix,
|
|
|
|
startup_info->prefix ? strlen(startup_info->prefix) : 0,
|
|
|
|
rel);
|
|
|
|
}
|
|
|
|
|
2012-07-03 01:32:11 +08:00
|
|
|
static int get_sha1_with_context_1(const char *name,
|
|
|
|
unsigned flags,
|
|
|
|
const char *prefix,
|
|
|
|
unsigned char *sha1,
|
|
|
|
struct object_context *oc)
|
2007-04-24 04:55:05 +08:00
|
|
|
{
|
|
|
|
int ret, bracket_depth;
|
2006-04-22 08:31:04 +08:00
|
|
|
int namelen = strlen(name);
|
|
|
|
const char *cp;
|
2012-07-03 01:32:11 +08:00
|
|
|
int only_to_die = flags & GET_SHA1_ONLY_TO_DIE;
|
2006-04-19 07:45:16 +08:00
|
|
|
|
2016-09-26 19:59:15 +08:00
|
|
|
if (only_to_die)
|
|
|
|
flags |= GET_SHA1_QUIETLY;
|
|
|
|
|
2010-06-10 01:02:06 +08:00
|
|
|
memset(oc, 0, sizeof(*oc));
|
|
|
|
oc->mode = S_IFINVALID;
|
2017-05-19 20:52:25 +08:00
|
|
|
strbuf_init(&oc->symlink_path, 0);
|
2012-07-03 01:32:11 +08:00
|
|
|
ret = get_sha1_1(name, namelen, sha1, flags);
|
2006-04-22 08:31:04 +08:00
|
|
|
if (!ret)
|
|
|
|
return ret;
|
2012-07-03 01:32:11 +08:00
|
|
|
/*
|
|
|
|
* sha1:path --> object name of path in ent sha1
|
2010-11-28 11:37:32 +08:00
|
|
|
* :path -> object name of absolute path in index
|
|
|
|
* :./path -> object name of path relative to cwd in index
|
2006-04-22 08:31:04 +08:00
|
|
|
* :[0-3]:path -> object name of path in index at stage
|
2010-09-25 00:43:59 +08:00
|
|
|
* :/foo -> recent commit matching foo
|
2006-04-22 08:31:04 +08:00
|
|
|
*/
|
|
|
|
if (name[0] == ':') {
|
|
|
|
int stage = 0;
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 23:29:00 +08:00
|
|
|
const struct cache_entry *ce;
|
2010-11-28 11:37:32 +08:00
|
|
|
char *new_path = NULL;
|
2006-04-22 08:31:04 +08:00
|
|
|
int pos;
|
fix overslow :/no-such-string-ever-existed diagnostics
"git cmd :/no-such-string-ever-existed" runs an extra round of get_sha1()
since 009fee4 (Detailed diagnosis when parsing an object name fails.,
2009-12-07). Once without error diagnosis to see there is no commit with
such a string in the log message (hence "it cannot be a ref"), and after
seeing that :/no-such-string-ever-existed is not a filename (hence "it
cannot be a path, either"), another time to give "better diagnosis".
The thing is, the second time it runs, we already know that traversing the
history all the way down to the root will _not_ find any matching commit.
Rename misguided "gently" parameter, which is turned off _only_ when the
"detailed diagnosis" codepath knows that it cannot be a ref and making the
call only for the caller to die with a message. Flip its meaning (and
adjust the callers) and call it "only_to_die", which is not a great name,
but it describes far more clearly what the codepaths that switches their
behaviour based on this variable do.
On my box, the command spends ~1.8 seconds without the patch to make the
report; with the patch it spends ~1.12 seconds.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-11 03:02:54 +08:00
|
|
|
if (!only_to_die && namelen > 2 && name[1] == '/') {
|
2010-12-13 11:01:14 +08:00
|
|
|
struct commit_list *list = NULL;
|
2015-05-26 02:38:28 +08:00
|
|
|
|
2010-12-13 11:01:14 +08:00
|
|
|
for_each_ref(handle_one_ref, &list);
|
2014-08-22 02:30:29 +08:00
|
|
|
commit_list_sort_by_date(&list);
|
2010-12-13 11:01:14 +08:00
|
|
|
return get_sha1_oneline(name + 2, sha1, list);
|
|
|
|
}
|
2006-04-22 08:31:04 +08:00
|
|
|
if (namelen < 3 ||
|
|
|
|
name[2] != ':' ||
|
|
|
|
name[1] < '0' || '3' < name[1])
|
|
|
|
cp = name + 1;
|
|
|
|
else {
|
|
|
|
stage = name[1] - '0';
|
|
|
|
cp = name + 3;
|
2006-04-19 07:45:16 +08:00
|
|
|
}
|
2010-12-10 05:38:05 +08:00
|
|
|
new_path = resolve_relative_path(cp);
|
|
|
|
if (!new_path) {
|
|
|
|
namelen = namelen - (cp - name);
|
|
|
|
} else {
|
|
|
|
cp = new_path;
|
|
|
|
namelen = strlen(cp);
|
|
|
|
}
|
2010-06-10 01:02:06 +08:00
|
|
|
|
2017-05-19 20:54:43 +08:00
|
|
|
if (flags & GET_SHA1_RECORD_PATH)
|
|
|
|
oc->path = xstrdup(cp);
|
2010-06-10 01:02:06 +08:00
|
|
|
|
2006-04-22 08:31:04 +08:00
|
|
|
if (!active_cache)
|
|
|
|
read_cache();
|
|
|
|
pos = cache_name_pos(cp, namelen);
|
|
|
|
if (pos < 0)
|
|
|
|
pos = -pos - 1;
|
|
|
|
while (pos < active_nr) {
|
|
|
|
ce = active_cache[pos];
|
|
|
|
if (ce_namelen(ce) != namelen ||
|
|
|
|
memcmp(ce->name, cp, namelen))
|
|
|
|
break;
|
|
|
|
if (ce_stage(ce) == stage) {
|
2016-09-06 04:07:52 +08:00
|
|
|
hashcpy(sha1, ce->oid.hash);
|
2010-09-29 19:35:24 +08:00
|
|
|
oc->mode = ce->ce_mode;
|
2010-11-28 11:37:32 +08:00
|
|
|
free(new_path);
|
2006-04-22 08:31:04 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2006-05-09 06:44:06 +08:00
|
|
|
pos++;
|
2006-04-22 08:31:04 +08:00
|
|
|
}
|
fix overslow :/no-such-string-ever-existed diagnostics
"git cmd :/no-such-string-ever-existed" runs an extra round of get_sha1()
since 009fee4 (Detailed diagnosis when parsing an object name fails.,
2009-12-07). Once without error diagnosis to see there is no commit with
such a string in the log message (hence "it cannot be a ref"), and after
seeing that :/no-such-string-ever-existed is not a filename (hence "it
cannot be a path, either"), another time to give "better diagnosis".
The thing is, the second time it runs, we already know that traversing the
history all the way down to the root will _not_ find any matching commit.
Rename misguided "gently" parameter, which is turned off _only_ when the
"detailed diagnosis" codepath knows that it cannot be a ref and making the
call only for the caller to die with a message. Flip its meaning (and
adjust the callers) and call it "only_to_die", which is not a great name,
but it describes far more clearly what the codepaths that switches their
behaviour based on this variable do.
On my box, the command spends ~1.8 seconds without the patch to make the
report; with the patch it spends ~1.12 seconds.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-11 03:02:54 +08:00
|
|
|
if (only_to_die && name[1] && name[1] != '/')
|
2009-12-07 18:10:50 +08:00
|
|
|
diagnose_invalid_index_path(stage, prefix, cp);
|
2010-11-28 11:37:32 +08:00
|
|
|
free(new_path);
|
2006-04-22 08:31:04 +08:00
|
|
|
return -1;
|
|
|
|
}
|
2006-05-19 15:29:43 +08:00
|
|
|
for (cp = name, bracket_depth = 0; *cp; cp++) {
|
|
|
|
if (*cp == '{')
|
|
|
|
bracket_depth++;
|
|
|
|
else if (bracket_depth && *cp == '}')
|
|
|
|
bracket_depth--;
|
|
|
|
else if (!bracket_depth && *cp == ':')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (*cp == ':') {
|
2006-04-22 08:31:04 +08:00
|
|
|
unsigned char tree_sha1[20];
|
2013-03-17 02:29:31 +08:00
|
|
|
int len = cp - name;
|
2016-09-26 19:59:41 +08:00
|
|
|
unsigned sub_flags = flags;
|
|
|
|
|
|
|
|
sub_flags &= ~GET_SHA1_DISAMBIGUATORS;
|
|
|
|
sub_flags |= GET_SHA1_TREEISH;
|
|
|
|
|
|
|
|
if (!get_sha1_1(name, len, tree_sha1, sub_flags)) {
|
2009-12-07 18:10:50 +08:00
|
|
|
const char *filename = cp+1;
|
2010-11-28 11:37:32 +08:00
|
|
|
char *new_filename = NULL;
|
|
|
|
|
|
|
|
new_filename = resolve_relative_path(filename);
|
|
|
|
if (new_filename)
|
|
|
|
filename = new_filename;
|
2015-05-21 01:03:39 +08:00
|
|
|
if (flags & GET_SHA1_FOLLOW_SYMLINKS) {
|
|
|
|
ret = get_tree_entry_follow_symlinks(tree_sha1,
|
|
|
|
filename, sha1, &oc->symlink_path,
|
|
|
|
&oc->mode);
|
|
|
|
} else {
|
|
|
|
ret = get_tree_entry(tree_sha1, filename,
|
|
|
|
sha1, &oc->mode);
|
|
|
|
if (ret && only_to_die) {
|
|
|
|
diagnose_invalid_sha1_path(prefix,
|
|
|
|
filename,
|
|
|
|
tree_sha1,
|
|
|
|
name, len);
|
|
|
|
}
|
2009-12-07 18:10:50 +08:00
|
|
|
}
|
2010-06-10 01:02:06 +08:00
|
|
|
hashcpy(oc->tree, tree_sha1);
|
2017-05-19 20:54:43 +08:00
|
|
|
if (flags & GET_SHA1_RECORD_PATH)
|
|
|
|
oc->path = xstrdup(filename);
|
2010-06-10 01:02:06 +08:00
|
|
|
|
2010-11-28 11:37:32 +08:00
|
|
|
free(new_filename);
|
2009-12-07 18:10:50 +08:00
|
|
|
return ret;
|
|
|
|
} else {
|
fix overslow :/no-such-string-ever-existed diagnostics
"git cmd :/no-such-string-ever-existed" runs an extra round of get_sha1()
since 009fee4 (Detailed diagnosis when parsing an object name fails.,
2009-12-07). Once without error diagnosis to see there is no commit with
such a string in the log message (hence "it cannot be a ref"), and after
seeing that :/no-such-string-ever-existed is not a filename (hence "it
cannot be a path, either"), another time to give "better diagnosis".
The thing is, the second time it runs, we already know that traversing the
history all the way down to the root will _not_ find any matching commit.
Rename misguided "gently" parameter, which is turned off _only_ when the
"detailed diagnosis" codepath knows that it cannot be a ref and making the
call only for the caller to die with a message. Flip its meaning (and
adjust the callers) and call it "only_to_die", which is not a great name,
but it describes far more clearly what the codepaths that switches their
behaviour based on this variable do.
On my box, the command spends ~1.8 seconds without the patch to make the
report; with the patch it spends ~1.12 seconds.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-11 03:02:54 +08:00
|
|
|
if (only_to_die)
|
2013-03-17 02:29:31 +08:00
|
|
|
die("Invalid object name '%.*s'.", len, name);
|
2009-12-07 18:10:50 +08:00
|
|
|
}
|
2006-04-19 07:45:16 +08:00
|
|
|
}
|
|
|
|
return ret;
|
2005-08-04 13:15:49 +08:00
|
|
|
}
|
2012-07-03 01:19:35 +08:00
|
|
|
|
2012-07-03 02:01:25 +08:00
|
|
|
/*
|
|
|
|
* Call this function when you know "name" given by the end user must
|
|
|
|
* name an object but it doesn't; the function _may_ die with a better
|
|
|
|
* diagnostic message than "no such object 'name'", e.g. "Path 'doc' does not
|
|
|
|
* exist in 'HEAD'" when given "HEAD:doc", or it may return in which case
|
|
|
|
* you have a chance to diagnose the error further.
|
|
|
|
*/
|
|
|
|
void maybe_die_on_misspelt_object_name(const char *name, const char *prefix)
|
2012-07-03 01:19:35 +08:00
|
|
|
{
|
|
|
|
struct object_context oc;
|
2012-07-03 02:01:25 +08:00
|
|
|
unsigned char sha1[20];
|
2012-07-03 01:32:11 +08:00
|
|
|
get_sha1_with_context_1(name, GET_SHA1_ONLY_TO_DIE, prefix, sha1, &oc);
|
2012-07-03 02:01:25 +08:00
|
|
|
}
|
|
|
|
|
2017-05-19 20:52:06 +08:00
|
|
|
int get_sha1_with_context(const char *str, unsigned flags, unsigned char *sha1, struct object_context *oc)
|
2012-07-03 01:19:35 +08:00
|
|
|
{
|
2015-05-21 01:03:39 +08:00
|
|
|
if (flags & GET_SHA1_FOLLOW_SYMLINKS && flags & GET_SHA1_ONLY_TO_DIE)
|
|
|
|
die("BUG: incompatible flags for get_sha1_with_context");
|
2017-05-19 20:52:06 +08:00
|
|
|
return get_sha1_with_context_1(str, flags, NULL, sha1, oc);
|
2012-07-03 01:19:35 +08:00
|
|
|
}
|