* [PATCH 2/7] push: add advice for rejected tag reference
From: Chris Rorvick @ 2012-11-23 4:21 UTC (permalink / raw)
To: git
Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras, Junio C Hamano
In-Reply-To: <1353644515-17349-1-git-send-email-chris@rorvick.com>
Advising the user to fetch and merge only makes sense if the rejected
reference is a branch. If none of the rejections are for branches, just
tell the user the reference already exists.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
builtin/push.c | 11 +++++++++++
cache.h | 1 +
remote.c | 10 ++++++++++
transport.c | 2 ++
transport.h | 1 +
5 files changed, 25 insertions(+)
diff --git a/builtin/push.c b/builtin/push.c
index 4a0e7ef..1391983 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -220,6 +220,10 @@ static const char message_advice_checkout_pull_push[] =
"(e.g. 'git pull') before pushing again.\n"
"See the 'Note about fast-forwards' in 'git push --help' for details.");
+static const char message_advice_ref_already_exists[] =
+ N_("Updates were rejected because the destination reference already exists\n"
+ "in the remote and the update is not a fast-forward.");
+
static void advise_pull_before_push(void)
{
if (!advice_push_non_ff_current || !advice_push_nonfastforward)
@@ -241,6 +245,11 @@ static void advise_checkout_pull_push(void)
advise(_(message_advice_checkout_pull_push));
}
+static void advise_ref_already_exists(void)
+{
+ advise(_(message_advice_ref_already_exists));
+}
+
static int push_with_options(struct transport *transport, int flags)
{
int err;
@@ -272,6 +281,8 @@ static int push_with_options(struct transport *transport, int flags)
advise_use_upstream();
else
advise_checkout_pull_push();
+ } else if (reject_mask & REJECT_ALREADY_EXISTS) {
+ advise_ref_already_exists();
}
return 1;
diff --git a/cache.h b/cache.h
index dbd8018..d72b64d 100644
--- a/cache.h
+++ b/cache.h
@@ -1002,6 +1002,7 @@ struct ref {
unsigned int force:1,
merge:1,
nonfastforward:1,
+ not_forwardable:1,
deletion:1;
enum {
REF_STATUS_NONE = 0,
diff --git a/remote.c b/remote.c
index 04fd9ea..5101683 100644
--- a/remote.c
+++ b/remote.c
@@ -1279,6 +1279,14 @@ int match_push_refs(struct ref *src, struct ref **dst,
return 0;
}
+static inline int is_forwardable(struct ref* ref)
+{
+ if (!prefixcmp(ref->name, "refs/tags/"))
+ return 0;
+
+ return 1;
+}
+
void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
int force_update)
{
@@ -1316,6 +1324,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
* always allowed.
*/
+ ref->not_forwardable = !is_forwardable(ref);
+
ref->nonfastforward =
!ref->deletion &&
!is_null_sha1(ref->old_sha1) &&
diff --git a/transport.c b/transport.c
index b0c9f1b..271965e 100644
--- a/transport.c
+++ b/transport.c
@@ -740,6 +740,8 @@ void transport_print_push_status(const char *dest, struct ref *refs,
ref->status != REF_STATUS_OK)
n += print_one_push_status(ref, dest, n, porcelain);
if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD) {
+ if (ref->not_forwardable)
+ *reject_mask |= REJECT_ALREADY_EXISTS;
if (!strcmp(head, ref->name))
*reject_mask |= REJECT_NON_FF_HEAD;
else
diff --git a/transport.h b/transport.h
index 5f76ca2..7e86352 100644
--- a/transport.h
+++ b/transport.h
@@ -142,6 +142,7 @@ void transport_set_verbosity(struct transport *transport, int verbosity,
#define REJECT_NON_FF_HEAD 0x01
#define REJECT_NON_FF_OTHER 0x02
+#define REJECT_ALREADY_EXISTS 0x04
int transport_push(struct transport *connection,
int refspec_nr, const char **refspec, int flags,
--
1.8.0.209.gf3828dc
^ permalink raw reply related
* [PATCH 1/7] push: return reject reasons via a mask
From: Chris Rorvick @ 2012-11-23 4:21 UTC (permalink / raw)
To: git
Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras, Junio C Hamano
In-Reply-To: <1353644515-17349-1-git-send-email-chris@rorvick.com>
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
builtin/push.c | 13 ++++---------
builtin/send-pack.c | 4 ++--
transport.c | 17 ++++++++---------
transport.h | 9 +++++----
4 files changed, 19 insertions(+), 24 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index db9ba30..4a0e7ef 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -244,7 +244,7 @@ static void advise_checkout_pull_push(void)
static int push_with_options(struct transport *transport, int flags)
{
int err;
- int nonfastforward;
+ unsigned int reject_mask;
transport_set_verbosity(transport, verbosity, progress);
@@ -257,7 +257,7 @@ static int push_with_options(struct transport *transport, int flags)
if (verbosity > 0)
fprintf(stderr, _("Pushing to %s\n"), transport->url);
err = transport_push(transport, refspec_nr, refspec, flags,
- &nonfastforward);
+ &reject_mask);
if (err != 0)
error(_("failed to push some refs to '%s'"), transport->url);
@@ -265,18 +265,13 @@ static int push_with_options(struct transport *transport, int flags)
if (!err)
return 0;
- switch (nonfastforward) {
- default:
- break;
- case NON_FF_HEAD:
+ if (reject_mask & REJECT_NON_FF_HEAD) {
advise_pull_before_push();
- break;
- case NON_FF_OTHER:
+ } else if (reject_mask & REJECT_NON_FF_OTHER) {
if (default_matching_used)
advise_use_upstream();
else
advise_checkout_pull_push();
- break;
}
return 1;
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index d342013..fda28bc 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -85,7 +85,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
int send_all = 0;
const char *receivepack = "git-receive-pack";
int flags;
- int nonfastforward = 0;
+ unsigned int reject_mask;
int progress = -1;
argv++;
@@ -223,7 +223,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
ret |= finish_connect(conn);
if (!helper_status)
- transport_print_push_status(dest, remote_refs, args.verbose, 0, &nonfastforward);
+ transport_print_push_status(dest, remote_refs, args.verbose, 0, &reject_mask);
if (!args.dry_run && remote) {
struct ref *ref;
diff --git a/transport.c b/transport.c
index 9932f40..b0c9f1b 100644
--- a/transport.c
+++ b/transport.c
@@ -714,7 +714,7 @@ static int print_one_push_status(struct ref *ref, const char *dest, int count, i
}
void transport_print_push_status(const char *dest, struct ref *refs,
- int verbose, int porcelain, int *nonfastforward)
+ int verbose, int porcelain, unsigned int *reject_mask)
{
struct ref *ref;
int n = 0;
@@ -733,18 +733,17 @@ void transport_print_push_status(const char *dest, struct ref *refs,
if (ref->status == REF_STATUS_OK)
n += print_one_push_status(ref, dest, n, porcelain);
- *nonfastforward = 0;
+ *reject_mask = 0;
for (ref = refs; ref; ref = ref->next) {
if (ref->status != REF_STATUS_NONE &&
ref->status != REF_STATUS_UPTODATE &&
ref->status != REF_STATUS_OK)
n += print_one_push_status(ref, dest, n, porcelain);
- if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD &&
- *nonfastforward != NON_FF_HEAD) {
+ if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD) {
if (!strcmp(head, ref->name))
- *nonfastforward = NON_FF_HEAD;
+ *reject_mask |= REJECT_NON_FF_HEAD;
else
- *nonfastforward = NON_FF_OTHER;
+ *reject_mask |= REJECT_NON_FF_OTHER;
}
}
}
@@ -1031,9 +1030,9 @@ static void die_with_unpushed_submodules(struct string_list *needs_pushing)
int transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags,
- int *nonfastforward)
+ unsigned int *reject_mask)
{
- *nonfastforward = 0;
+ *reject_mask = 0;
transport_verify_remote_names(refspec_nr, refspec);
if (transport->push) {
@@ -1099,7 +1098,7 @@ int transport_push(struct transport *transport,
if (!quiet || err)
transport_print_push_status(transport->url, remote_refs,
verbose | porcelain, porcelain,
- nonfastforward);
+ reject_mask);
if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
set_upstreams(transport, remote_refs, pretend);
diff --git a/transport.h b/transport.h
index 4a61c0c..5f76ca2 100644
--- a/transport.h
+++ b/transport.h
@@ -140,11 +140,12 @@ int transport_set_option(struct transport *transport, const char *name,
void transport_set_verbosity(struct transport *transport, int verbosity,
int force_progress);
-#define NON_FF_HEAD 1
-#define NON_FF_OTHER 2
+#define REJECT_NON_FF_HEAD 0x01
+#define REJECT_NON_FF_OTHER 0x02
+
int transport_push(struct transport *connection,
int refspec_nr, const char **refspec, int flags,
- int * nonfastforward);
+ unsigned int * reject_mask);
const struct ref *transport_get_remote_refs(struct transport *transport);
@@ -170,7 +171,7 @@ void transport_update_tracking_ref(struct remote *remote, struct ref *ref, int v
int transport_refs_pushed(struct ref *ref);
void transport_print_push_status(const char *dest, struct ref *refs,
- int verbose, int porcelain, int *nonfastforward);
+ int verbose, int porcelain, unsigned int *reject_mask);
typedef void alternate_ref_fn(const struct ref *, void *);
extern void for_each_alternate_ref(alternate_ref_fn, void *);
--
1.8.0.209.gf3828dc
^ permalink raw reply related
* [PATCH 4/7] push: flag updates that require force
From: Chris Rorvick @ 2012-11-23 4:21 UTC (permalink / raw)
To: git
Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras, Junio C Hamano
In-Reply-To: <1353644515-17349-1-git-send-email-chris@rorvick.com>
Add a flag for indicating an update to a reference requires force.
Currently the nonfastforward flag of a ref is used for this when
generating status the status message. A separate flag insulates the
status logic from the details of set_ref_status_for_push().
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
cache.h | 4 +++-
remote.c | 11 ++++++++---
transport.c | 2 +-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index 722321c..b7ab4ac 100644
--- a/cache.h
+++ b/cache.h
@@ -999,7 +999,9 @@ struct ref {
unsigned char old_sha1[20];
unsigned char new_sha1[20];
char *symref;
- unsigned int force:1,
+ unsigned int
+ force:1,
+ requires_force:1,
merge:1,
nonfastforward:1,
not_forwardable:1,
diff --git a/remote.c b/remote.c
index 07040b8..4a6f822 100644
--- a/remote.c
+++ b/remote.c
@@ -1293,6 +1293,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
struct ref *ref;
for (ref = remote_refs; ref; ref = ref->next) {
+ int force_ref_update = ref->force || force_update;
+
if (ref->peer_ref)
hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
else if (!send_mirror)
@@ -1335,9 +1337,12 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
!has_sha1_file(ref->old_sha1)
|| !ref_newer(ref->new_sha1, ref->old_sha1);
- if (ref->nonfastforward && !ref->force && !force_update) {
- ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
- continue;
+ if (ref->nonfastforward) {
+ ref->requires_force = 1;
+ if (!force_ref_update) {
+ ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ continue;
+ }
}
}
}
diff --git a/transport.c b/transport.c
index 271965e..ea8bbbd 100644
--- a/transport.c
+++ b/transport.c
@@ -659,7 +659,7 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
const char *msg;
strcpy(quickref, status_abbrev(ref->old_sha1));
- if (ref->nonfastforward) {
+ if (ref->requires_force) {
strcat(quickref, "...");
type = '+';
msg = "forced update";
--
1.8.0.209.gf3828dc
^ permalink raw reply related
* [PATCH 3/7] push: flag updates
From: Chris Rorvick @ 2012-11-23 4:21 UTC (permalink / raw)
To: git
Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras, Junio C Hamano
In-Reply-To: <1353644515-17349-1-git-send-email-chris@rorvick.com>
If the reference exists on the remote and the update is not a delete,
then mark as an update. This is in preparation for handling tags and
branches differently when pushing.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
cache.h | 1 +
remote.c | 18 +++++++++++-------
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index d72b64d..722321c 100644
--- a/cache.h
+++ b/cache.h
@@ -1003,6 +1003,7 @@ struct ref {
merge:1,
nonfastforward:1,
not_forwardable:1,
+ update:1,
deletion:1;
enum {
REF_STATUS_NONE = 0,
diff --git a/remote.c b/remote.c
index 5101683..07040b8 100644
--- a/remote.c
+++ b/remote.c
@@ -1326,15 +1326,19 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
ref->not_forwardable = !is_forwardable(ref);
- ref->nonfastforward =
+ ref->update =
!ref->deletion &&
- !is_null_sha1(ref->old_sha1) &&
- (!has_sha1_file(ref->old_sha1)
- || !ref_newer(ref->new_sha1, ref->old_sha1));
+ !is_null_sha1(ref->old_sha1);
- if (ref->nonfastforward && !ref->force && !force_update) {
- ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
- continue;
+ if (ref->update) {
+ ref->nonfastforward =
+ !has_sha1_file(ref->old_sha1)
+ || !ref_newer(ref->new_sha1, ref->old_sha1);
+
+ if (ref->nonfastforward && !ref->force && !force_update) {
+ ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ continue;
+ }
}
}
}
--
1.8.0.209.gf3828dc
^ permalink raw reply related
* [PATCH 7/7] push: clarify rejection of update to non-commit-ish
From: Chris Rorvick @ 2012-11-23 4:21 UTC (permalink / raw)
To: git
Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras, Junio C Hamano
In-Reply-To: <1353644515-17349-1-git-send-email-chris@rorvick.com>
Pushes must already (by default) update to a commit-ish due the fast-
forward check in set_ref_status_for_push(). But rejecting for not being
a fast-forward suggests the situation can be resolved with a merge.
Flag these updates (i.e., to a blob or a tree) as not forwardable so the
user is presented with more appropriate advice.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
remote.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/remote.c b/remote.c
index f5bc4e7..ee0c1e5 100644
--- a/remote.c
+++ b/remote.c
@@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref* ref)
if (!o || o->type != OBJ_COMMIT)
return 0;
+ /* new object must be commit-ish */
+ o = deref_tag(parse_object(ref->new_sha1), NULL, 0);
+ if (!o || o->type != OBJ_COMMIT)
+ return 0;
+
return 1;
}
--
1.8.0.209.gf3828dc
^ permalink raw reply related
* [PATCH 5/7] push: require force for refs under refs/tags/
From: Chris Rorvick @ 2012-11-23 4:21 UTC (permalink / raw)
To: git
Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras, Junio C Hamano
In-Reply-To: <1353644515-17349-1-git-send-email-chris@rorvick.com>
References are allowed to update from one commit-ish to another if the
former is an ancestor of the latter. This behavior is oriented to
branches which are expected to move with commits. Tag references are
expected to be static in a repository, though, thus an update to
something under refs/tags/ should be rejected unless the update is
forced.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
Documentation/git-push.txt | 11 ++++++-----
builtin/push.c | 2 +-
builtin/send-pack.c | 5 +++++
cache.h | 1 +
remote.c | 18 ++++++++++++++----
send-pack.c | 1 +
t/t5516-fetch-push.sh | 23 ++++++++++++++++++++++-
transport-helper.c | 6 ++++++
transport.c | 8 ++++++--
9 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fe46c42..09bdec7 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -51,11 +51,12 @@ be named. If `:`<dst> is omitted, the same ref as <src> will be
updated.
+
The object referenced by <src> is used to update the <dst> reference
-on the remote side, but by default this is only allowed if the
-update can fast-forward <dst>. By having the optional leading `+`,
-you can tell git to update the <dst> ref even when the update is not a
-fast-forward. This does *not* attempt to merge <src> into <dst>. See
-EXAMPLES below for details.
+on the remote side. By default this is only allowed if <dst> is not
+under refs/tags/, and then only if it can fast-forward <dst>. By having
+the optional leading `+`, you can tell git to update the <dst> ref even
+if it is not allowed by default (e.g., it is not a fast-forward.) This
+does *not* attempt to merge <src> into <dst>. See EXAMPLES below for
+details.
+
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+
diff --git a/builtin/push.c b/builtin/push.c
index 1391983..2143833 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -222,7 +222,7 @@ static const char message_advice_checkout_pull_push[] =
static const char message_advice_ref_already_exists[] =
N_("Updates were rejected because the destination reference already exists\n"
- "in the remote and the update is not a fast-forward.");
+ "in the remote.");
static void advise_pull_before_push(void)
{
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index fda28bc..1eabf42 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -44,6 +44,11 @@ static void print_helper_status(struct ref *ref)
msg = "non-fast forward";
break;
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
+ res = "error";
+ msg = "already exists";
+ break;
+
case REF_STATUS_REJECT_NODELETE:
case REF_STATUS_REMOTE_REJECT:
res = "error";
diff --git a/cache.h b/cache.h
index b7ab4ac..a32a0ea 100644
--- a/cache.h
+++ b/cache.h
@@ -1011,6 +1011,7 @@ struct ref {
REF_STATUS_NONE = 0,
REF_STATUS_OK,
REF_STATUS_REJECT_NONFASTFORWARD,
+ REF_STATUS_REJECT_ALREADY_EXISTS,
REF_STATUS_REJECT_NODELETE,
REF_STATUS_UPTODATE,
REF_STATUS_REMOTE_REJECT,
diff --git a/remote.c b/remote.c
index 4a6f822..012b52f 100644
--- a/remote.c
+++ b/remote.c
@@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
*
* (1) if the old thing does not exist, it is OK.
*
- * (2) if you do not have the old thing, you are not allowed
+ * (2) if the destination is under refs/tags/ you are
+ * not allowed to overwrite it; tags are expected
+ * to be static once created
+ *
+ * (3) if you do not have the old thing, you are not allowed
* to overwrite it; you would not know what you are losing
* otherwise.
*
- * (3) if both new and old are commit-ish, and new is a
+ * (4) if both new and old are commit-ish, and new is a
* descendant of old, it is OK.
*
- * (4) regardless of all of the above, removing :B is
+ * (5) regardless of all of the above, removing :B is
* always allowed.
*/
@@ -1337,7 +1341,13 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
!has_sha1_file(ref->old_sha1)
|| !ref_newer(ref->new_sha1, ref->old_sha1);
- if (ref->nonfastforward) {
+ if (ref->not_forwardable) {
+ ref->requires_force = 1;
+ if (!force_ref_update) {
+ ref->status = REF_STATUS_REJECT_ALREADY_EXISTS;
+ continue;
+ }
+ } else if (ref->nonfastforward) {
ref->requires_force = 1;
if (!force_ref_update) {
ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
diff --git a/send-pack.c b/send-pack.c
index f50dfd9..1c375f0 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -229,6 +229,7 @@ int send_pack(struct send_pack_args *args,
/* Check for statuses set by set_ref_status_for_push() */
switch (ref->status) {
case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
case REF_STATUS_UPTODATE:
continue;
default:
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index b5417cc..8f024a0 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -368,7 +368,7 @@ test_expect_success 'push with colon-less refspec (2)' '
git branch -D frotz
fi &&
git tag -f frotz &&
- git push testrepo frotz &&
+ git push -f testrepo frotz &&
check_push_result $the_commit tags/frotz &&
check_push_result $the_first_commit heads/frotz
@@ -929,6 +929,27 @@ test_expect_success 'push into aliased refs (inconsistent)' '
)
'
+test_expect_success 'push requires --force to update lightweight tag' '
+ mk_test heads/master &&
+ mk_child child1 &&
+ mk_child child2 &&
+ (
+ cd child1 &&
+ git tag Tag &&
+ git push ../child2 Tag &&
+ git push ../child2 Tag &&
+ >file1 &&
+ git add file1 &&
+ git commit -m "file1" &&
+ git tag -f Tag &&
+ test_must_fail git push ../child2 Tag &&
+ git push --force ../child2 Tag &&
+ git tag -f Tag &&
+ test_must_fail git push ../child2 Tag HEAD~ &&
+ git push --force ../child2 Tag
+ )
+'
+
test_expect_success 'push --porcelain' '
mk_empty &&
echo >.git/foo "To testrepo" &&
diff --git a/transport-helper.c b/transport-helper.c
index 4713b69..965b778 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -661,6 +661,11 @@ static void push_update_ref_status(struct strbuf *buf,
free(msg);
msg = NULL;
}
+ else if (!strcmp(msg, "already exists")) {
+ status = REF_STATUS_REJECT_ALREADY_EXISTS;
+ free(msg);
+ msg = NULL;
+ }
}
if (*ref)
@@ -720,6 +725,7 @@ static int push_refs_with_push(struct transport *transport,
/* Check for statuses set by set_ref_status_for_push() */
switch (ref->status) {
case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
case REF_STATUS_UPTODATE:
continue;
default:
diff --git a/transport.c b/transport.c
index ea8bbbd..a380ad7 100644
--- a/transport.c
+++ b/transport.c
@@ -695,6 +695,10 @@ static int print_one_push_status(struct ref *ref, const char *dest, int count, i
print_ref_status('!', "[rejected]", ref, ref->peer_ref,
"non-fast-forward", porcelain);
break;
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
+ print_ref_status('!', "[rejected]", ref, ref->peer_ref,
+ "already exists", porcelain);
+ break;
case REF_STATUS_REMOTE_REJECT:
print_ref_status('!', "[remote rejected]", ref,
ref->deletion ? NULL : ref->peer_ref,
@@ -740,12 +744,12 @@ void transport_print_push_status(const char *dest, struct ref *refs,
ref->status != REF_STATUS_OK)
n += print_one_push_status(ref, dest, n, porcelain);
if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD) {
- if (ref->not_forwardable)
- *reject_mask |= REJECT_ALREADY_EXISTS;
if (!strcmp(head, ref->name))
*reject_mask |= REJECT_NON_FF_HEAD;
else
*reject_mask |= REJECT_NON_FF_OTHER;
+ } else if (ref->status == REF_STATUS_REJECT_ALREADY_EXISTS) {
+ *reject_mask |= REJECT_ALREADY_EXISTS;
}
}
}
--
1.8.0.209.gf3828dc
^ permalink raw reply related
* [PATCH 6/7] push: require force for annotated tags
From: Chris Rorvick @ 2012-11-23 4:21 UTC (permalink / raw)
To: git
Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras, Junio C Hamano
In-Reply-To: <1353644515-17349-1-git-send-email-chris@rorvick.com>
Do not allow fast-forwarding of references that point to a tag object.
This keeps the behavior consistent with lightweight tags. Additionally,
allowing the reference to update could leave the old object dangling.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
Documentation/git-push.txt | 10 +++++-----
remote.c | 11 +++++++++--
t/t5516-fetch-push.sh | 21 +++++++++++++++++++++
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 09bdec7..7a04ce5 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -52,11 +52,11 @@ updated.
+
The object referenced by <src> is used to update the <dst> reference
on the remote side. By default this is only allowed if <dst> is not
-under refs/tags/, and then only if it can fast-forward <dst>. By having
-the optional leading `+`, you can tell git to update the <dst> ref even
-if it is not allowed by default (e.g., it is not a fast-forward.) This
-does *not* attempt to merge <src> into <dst>. See EXAMPLES below for
-details.
+a tag (annotated or lightweight), and then only if it can fast-forward
+<dst>. By having the optional leading `+`, you can tell git to update
+the <dst> ref even if it is not allowed by default (e.g., it is not a
+fast-forward.) This does *not* attempt to merge <src> into <dst>. See
+EXAMPLES below for details.
+
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+
diff --git a/remote.c b/remote.c
index 012b52f..f5bc4e7 100644
--- a/remote.c
+++ b/remote.c
@@ -1281,9 +1281,16 @@ int match_push_refs(struct ref *src, struct ref **dst,
static inline int is_forwardable(struct ref* ref)
{
+ struct object *o;
+
if (!prefixcmp(ref->name, "refs/tags/"))
return 0;
+ /* old object must be a commit */
+ o = parse_object(ref->old_sha1);
+ if (!o || o->type != OBJ_COMMIT)
+ return 0;
+
return 1;
}
@@ -1323,8 +1330,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
* to overwrite it; you would not know what you are losing
* otherwise.
*
- * (4) if both new and old are commit-ish, and new is a
- * descendant of old, it is OK.
+ * (4) if old is a commit and new is a descendant of old
+ * (implying new is commit-ish), it is OK.
*
* (5) regardless of all of the above, removing :B is
* always allowed.
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 8f024a0..6009372 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -950,6 +950,27 @@ test_expect_success 'push requires --force to update lightweight tag' '
)
'
+test_expect_success 'push requires --force to update annotated tag' '
+ mk_test heads/master &&
+ mk_child child1 &&
+ mk_child child2 &&
+ (
+ cd child1 &&
+ git tag -a -m "message 1" Tag &&
+ git push ../child2 Tag:refs/tmp/Tag &&
+ git push ../child2 Tag:refs/tmp/Tag &&
+ >file1 &&
+ git add file1 &&
+ git commit -m "file1" &&
+ git tag -f -a -m "message 2" Tag &&
+ test_must_fail git push ../child2 Tag:refs/tmp/Tag &&
+ git push --force ../child2 Tag:refs/tmp/Tag &&
+ git tag -f -a -m "message 3" Tag HEAD~ &&
+ test_must_fail git push ../child2 Tag:refs/tmp/Tag &&
+ git push --force ../child2 Tag:refs/tmp/Tag
+ )
+'
+
test_expect_success 'push --porcelain' '
mk_empty &&
echo >.git/foo "To testrepo" &&
--
1.8.0.209.gf3828dc
^ permalink raw reply related
* [PATCH] gitk tag delete/rename support
From: Leon KUKOVEC @ 2012-11-23 5:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Leon KUKOVEC
---
gitk-git/gitk | 154 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 154 insertions(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 17ba10a..12a7139 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1981,6 +1981,7 @@ proc makewindow {} {
global have_tk85 use_ttk NS
global git_version
global worddiff
+ global tagctxmenu
# The "mc" arguments here are purely so that xgettext
# sees the following string as needing to be translated
@@ -2526,6 +2527,13 @@ proc makewindow {} {
{mc "Run git gui blame on this line" command {external_blame_diff}}
}
$diff_menu configure -tearoff 0
+
+ set tagctxmenu .tagctxmenu
+ makemenu $tagctxmenu {
+ {mc "Rename this tag" command mvtag}
+ {mc "Delete this tag" command rmtag}
+ }
+ $tagctxmenu configure -tearoff 0
}
# Windows sends all mouse wheel events to the current focused window, not
@@ -6345,6 +6353,7 @@ proc drawtags {id x xt y1} {
-font $font -tags [list tag.$id text]]
if {$ntags >= 0} {
$canv bind $t <1> [list showtag $tag_quoted 1]
+ $canv bind $t $ctxbut [list showtagmenu %X %Y $id $tag_quoted]
} elseif {$nheads >= 0} {
$canv bind $t $ctxbut [list headmenu %X %Y $id $tag_quoted]
}
@@ -8857,6 +8866,113 @@ proc domktag {} {
return 1
}
+proc mvtag {} {
+ global mvtagtop
+ global tagmenuid tagmenutag tagctxmenu maintag NS
+ global mvtagtag
+
+ set mvtagtag $tagmenutag
+ set top .movetag
+ set mvtagtop $top
+ catch {destroy $top}
+ ttk_toplevel $top
+ make_transient $top .
+
+ ${NS}::label $top.msg -text [mc "Enter a new tag name:"]
+ ${NS}::entry $top.tag -width 60 -textvariable mvtagtag
+
+ grid $top.msg -sticky w -row 0 -column 0
+ grid $top.tag -sticky w -row 0 -column 1
+
+ ${NS}::frame $top.buts
+ ${NS}::button $top.buts.gen -text [mc "Rename"] -command mvtaggo
+ ${NS}::button $top.buts.can -text [mc "Cancel"] -command mvtagcan
+ bind $top <Key-Return> mvtaggo
+ bind $top <Key-Escape> mvtagcan
+ grid $top.buts.gen $top.buts.can
+ grid columnconfigure $top.buts 0 -weight 1 -uniform a
+ grid columnconfigure $top.buts 1 -weight 1 -uniform a
+ grid $top.buts - -pady 10 -sticky ew
+}
+
+proc domvtag {} {
+ global mvtagtop env tagids idtags tagmenutag tagmenuid mvtagtag
+
+ set tag $mvtagtag
+ set id $tagmenuid
+
+ # add tag
+ # XXX: reuse domktag including keeping comment from the original tag.
+ if {[catch {
+ exec git tag $tag $id
+ } err]} {
+ error_popup "[mc "Error renaming tag:"] $err" $mvtagtop
+ return 0
+ }
+
+ # delete old tag, content stored in $tagmenutag and $tagmenuid
+ dormtag
+
+ set tagids($tag) $id
+ lappend idtags($id) $tag
+ redrawtags $id
+ addedtag $id
+ dispneartags 0
+ run refill_reflist
+ return 1
+}
+
+proc rmtag {} {
+ global rmtagtop
+ global tagmenuid tagmenutag tagctxmenu maintag NS
+
+ set top .maketag
+ set rmtagtop $top
+ catch {destroy $top}
+ ttk_toplevel $top
+ make_transient $top .
+ ${NS}::label $top.title -text [mc "Delete tag"]
+ grid $top.title - -pady 10
+
+ ${NS}::label $top.msg -text [mc "You are about to delete a tag"]
+ ${NS}::label $top.tagname -foreground Red -text [mc "$tagmenutag"]
+ grid $top.msg -sticky w -row 0 -column 0
+ grid $top.tagname -sticky w -row 0 -column 1
+
+ ${NS}::frame $top.buts
+ ${NS}::button $top.buts.gen -text [mc "Delete"] -command rmtaggo
+ ${NS}::button $top.buts.can -text [mc "Cancel"] -command rmtagcan
+ bind $top <Key-Return> rmtaggo
+ bind $top <Key-Escape> rmtagcan
+ grid $top.buts.gen $top.buts.can
+ grid columnconfigure $top.buts 0 -weight 1 -uniform a
+ grid columnconfigure $top.buts 1 -weight 1 -uniform a
+ grid $top.buts - -pady 10 -sticky ew
+}
+
+proc dormtag {} {
+ global rmtagtop env tagids idtags tagmenutag tagmenuid
+
+ set tag $tagmenutag
+ set id $tagmenuid
+
+ if {[catch {
+ exec git tag -d $tag
+ } err]} {
+ error_popup "[mc "Error deleting tag:"] $err" $rmtagtop
+ return 0
+ }
+
+ unset tagids($tag)
+ set idx [lsearch $idtags($id) $tag]
+ set idtags($id) [lreplace $idtags($id) $idx $idx]
+
+ redrawtags $id
+ dispneartags 0
+ run refill_reflist
+ return 1
+}
+
proc redrawtags {id} {
global canv linehtag idpos currentid curview cmitlisted markedid
global canvxmax iddrawn circleitem mainheadid circlecolors
@@ -8900,6 +9016,30 @@ proc mktaggo {} {
mktagcan
}
+proc rmtagcan {} {
+ global rmtagtop
+
+ catch {destroy $rmtagtop}
+ unset rmtagtop
+}
+
+proc rmtaggo {} {
+ if {![dormtag]} return
+ rmtagcan
+}
+
+proc mvtagcan {} {
+ global mvtagtop
+
+ catch {destroy $mvtagtop}
+ unset mvtagtop
+}
+
+proc mvtaggo {} {
+ if {![domvtag]} return
+ mvtagcan
+}
+
proc writecommit {} {
global rowmenuid wrcomtop commitinfo wrcomcmd NS
@@ -9214,6 +9354,20 @@ proc headmenu {x y id head} {
tk_popup $headctxmenu $x $y
}
+# context menu for a tag
+proc showtagmenu {x y id tag} {
+ global tagmenuid tagmenutag tagctxmenu maintag
+
+ stopfinding
+ set tagmenuid $id
+ set tagmenutag $tag
+ set state normal
+
+ $tagctxmenu entryconfigure 0 -state normal
+ $tagctxmenu entryconfigure 1 -state normal
+ tk_popup $tagctxmenu $x $y
+}
+
proc cobranch {} {
global headmenuid headmenuhead headids
global showlocalchanges
--
1.7.9.5
^ permalink raw reply related
* New git.pot is generated for the start of git 1.8.1 l10n
From: Jiang Xin @ 2012-11-23 6:58 UTC (permalink / raw)
To: Byrial Jensen, Ralf Thielow,
Ævar Arnfjörð Bjarmason, Marco Paolone,
Vincent van Ravesteijn, Marco Sousa, Peter Krefting,
Trần Ngọc Quân, David Hrbáč
Cc: Git List, Junio C Hamano
Dear l10n team members,
New "git.pot" is generated from v1.8.0-273-g2d242 in the master branch.
l10n: Update git.pot (14 new, 3 removed messages)
Generate po/git.pot from v1.8.0-273-g2d242, and there are 14 new and 3
removed messages.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
This update is for the l10n of upcoming git 1.8.1. You can get it from
the usual place:
https://github.com/git-l10n/git-po/
BTW, I'm sorry for this late, because these 2 months I am on a project and
have hardly any spare time. Push me using email if I am late again.
--
Jiang Xin
^ permalink raw reply
* [PATCH] diff: Fixes shortstat number of files
From: Antoine Pelisse @ 2012-11-23 7:33 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
There is a discrepancy between the last line of `git diff --stat`
and `git diff --shortstat` in case of a merge.
The unmerged files are actually counted twice, thus doubling the
value of "file changed".
In fact, while stat decrements number of files when seeing an unmerged
file, shortstat doesn't.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
diff.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index e89a201..5c6bcbd 100644
--- a/diff.c
+++ b/diff.c
@@ -1704,9 +1704,8 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option
int added = data->files[i]->added;
int deleted= data->files[i]->deleted;
- if (data->files[i]->is_unmerged)
- continue;
- if (!data->files[i]->is_renamed && (added + deleted == 0)) {
+ if (data->files[i]->is_unmerged ||
+ (!data->files[i]->is_renamed && (added + deleted == 0))) {
total_files--;
} else if (!data->files[i]->is_binary) { /* don't count bytes */
adds += added;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] Completion must sort before using uniq
From: Joachim Schmitz @ 2012-11-23 8:09 UTC (permalink / raw)
To: git
In-Reply-To: <CAFj1UpF2wh0imcqW7Ez_J14R_07a_A1-YWESaGrHRNa7Nsv-xg@mail.gmail.com>
Marc Khouzam wrote:
> The uniq program only works with sorted input. The man page states
> "uniq prints the unique lines in a sorted file".
...
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -321,7 +321,7 @@ __git_refs ()
> if [[ "$ref" == "$cur"* ]]; then
> echo "$ref"
> fi
> - done | uniq -u
> + done | sort | uniq -u
Is 'sort -u' not universally available and sufficient here? It is POSIX at
least:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html
Bye, Jojo
^ permalink raw reply
* Re: [PATCH] Completion must sort before using uniq
From: Felipe Contreras @ 2012-11-23 8:21 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git, SZEDER Gábor
In-Reply-To: <CAFj1UpF2wh0imcqW7Ez_J14R_07a_A1-YWESaGrHRNa7Nsv-xg@mail.gmail.com>
On Thu, Nov 22, 2012 at 5:16 AM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> The uniq program only works with sorted input. The man page states
> "uniq prints the unique lines in a sorted file".
>
> When __git_refs use the guess heuristic employed by checkout for
> tracking branches it wants to consider remote branches but only if
> the branch name is unique. To do that, it calls 'uniq -u'. However
> the input given to 'uniq -u' is not sorted.
>
> For example if all available branches are:
> master
> remotes/GitHub/maint
> remotes/GitHub/master
> remotes/origin/maint
> remotes/origin/master
>
> When performing completion on 'git checkout ma' the choices given are
> maint
> master
> but when performing completion on 'git checkout mai', no choices
> appear, which is obviously contradictory.
>
> The reason is that, when dealing with 'git checkout ma',
> "__git_refs '' 1" will find the following list:
> master
> maint
> master
> maint
> master
> which, when passed to 'uniq -u' will remain the same.
> But when dealing with 'git checkout mai', the list will be:
> maint
> maint
> which happens to be sorted and will be emptied by 'uniq -u'.
>
> The solution is to first call 'sort' and then 'uniq -u'.
The solution to what? This seems to be the right thing indeed, but you
don't explain what is the actual problem that is being solved. What
does the user experience? What would (s)he experience after the patch?
--
Felipe Contreras
^ permalink raw reply
* [RFC/PATCH] Option to revert order of parents in merge commit
From: Kacper Kornet @ 2012-11-23 8:35 UTC (permalink / raw)
To: git
When the changes are pushed upstream, and in the meantime someone else
updated upstream branch git advises to use git pull. This results in
history:
---A---B---C--
\ /
D---E
where B is my commit. D, E are commits pushed by someone else when I was
working on B. However sometimes the following history is preferable:
---A---D---C'--
\ /
-B-
The difference between C and C' is the order of parents. Presently to
obtain it, instead of git pull, one needs to do (assuming that I am on
the master branch):
git fetch origin
git branch tmp_branch
git reset --hard origin/master
git merge tmp_branch
Reverting from wrong pull is more cumbersome. It would be simpler if git
merge learn an option to reverse order of parents in the produced
commits, so one could do:
git fetch origin
git merge --revert-order origin/master
The following patch is an attempt to implement this idea.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
---
I'm not 100% percent sure that it is a good idea. But it would make life
of our developers easier and produced nicer history then using git pull.
Git pull seems to written for a case of single maintainer who gathers
contributions from other developers and incorporates them in master
branch. However in my opinion it doesn't produce best history when many
developers modify the canonical repository.
builtin/commit.c | 22 ++++++++++++++--------
builtin/merge.c | 16 ++++++++++++----
commit.c | 11 +++++++++++
commit.h | 2 ++
4 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 1dd2ec5..ab2b844 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1427,7 +1427,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = &parents;
- struct stat statbuf;
int allow_fast_forward = 1;
struct commit *current_head = NULL;
struct commit_extra_header *extra = NULL;
@@ -1478,10 +1477,21 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
} else if (whence == FROM_MERGE) {
struct strbuf m = STRBUF_INIT;
FILE *fp;
+ int reversed_order=0;
if (!reflog_msg)
reflog_msg = "commit (merge)";
- pptr = &commit_list_insert(current_head, pptr)->next;
+ if((fp = fopen(git_path("MERGE_MODE"), "r"))) {
+ while (strbuf_getline(&m, fp, '\n') != EOF) {
+ if (!strcmp(m.buf, "no-ff"))
+ allow_fast_forward = 0;
+ if (!strcmp(m.buf, "reversed-order"))
+ reversed_order = 1;
+ }
+ fclose(fp);
+ }
+ if (!reversed_order)
+ pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
die_errno(_("could not open '%s' for reading"),
@@ -1496,12 +1506,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
fclose(fp);
strbuf_release(&m);
- if (!stat(git_path("MERGE_MODE"), &statbuf)) {
- if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 0)
- die_errno(_("could not read MERGE_MODE"));
- if (!strcmp(sb.buf, "no-ff"))
- allow_fast_forward = 0;
- }
+ if (reversed_order)
+ pptr = &commit_list_insert(current_head, pptr)->next;
if (allow_fast_forward)
parents = reduce_heads(parents);
} else {
diff --git a/builtin/merge.c b/builtin/merge.c
index a96e8ea..8d0ed18 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -65,6 +65,7 @@ static int abort_current_merge;
static int show_progress = -1;
static int default_to_upstream;
static const char *sign_commit;
+static int reversed_order=0;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -213,6 +214,7 @@ static struct option builtin_merge_options[] = {
{ OPTION_STRING, 'S', "gpg-sign", &sign_commit, N_("key id"),
N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
OPT_BOOLEAN(0, "overwrite-ignore", &overwrite_ignore, N_("update ignored files (default)")),
+ OPT_BOOLEAN(0, "revert-order", &reversed_order, N_("reverse order of parents")),
OPT_END()
};
@@ -822,9 +824,9 @@ static int merge_trivial(struct commit *head, struct commit_list *remoteheads)
write_tree_trivial(result_tree);
printf(_("Wonderful.\n"));
- parent->item = head;
+ parent->item = reversed_order ? remoteheads->item : head;
parent->next = xmalloc(sizeof(*parent->next));
- parent->next->item = remoteheads->item;
+ parent->next->item = reversed_order ? head : remoteheads->item;
parent->next->next = NULL;
prepare_to_commit(remoteheads);
if (commit_tree(&merge_msg, result_tree, parent, result_commit, NULL,
@@ -848,8 +850,12 @@ static int finish_automerge(struct commit *head,
free_commit_list(common);
parents = remoteheads;
- if (!head_subsumed || !allow_fast_forward)
+ if (!head_subsumed || !allow_fast_forward) {
+ if (reversed_order )
+ commit_list_insert_end(head, &parents);
+ else
commit_list_insert(head, &parents);
+ }
strbuf_addch(&merge_msg, '\n');
prepare_to_commit(remoteheads);
if (commit_tree(&merge_msg, result_tree, parents, result_commit,
@@ -994,7 +1000,9 @@ static void write_merge_state(struct commit_list *remoteheads)
die_errno(_("Could not open '%s' for writing"), filename);
strbuf_reset(&buf);
if (!allow_fast_forward)
- strbuf_addf(&buf, "no-ff");
+ strbuf_addf(&buf, "no-ff\n");
+ if (reversed_order)
+ strbuf_addf(&buf, "reversed-order\n");
if (write_in_full(fd, buf.buf, buf.len) != buf.len)
die_errno(_("Could not write to '%s'"), filename);
close(fd);
diff --git a/commit.c b/commit.c
index e8eb0ae..6e58994 100644
--- a/commit.c
+++ b/commit.c
@@ -363,6 +363,17 @@ struct commit_list *commit_list_insert(struct commit *item, struct commit_list *
return new_list;
}
+struct commit_list *commit_list_insert_end(struct commit *item, struct commit_list **list_p)
+{
+ struct commit_list *list_iter = *list_p;
+ while(list_iter->next)
+ list_iter = list_iter->next;
+ list_iter->next = xmalloc(sizeof(*list_iter->next));
+ list_iter->next->item = item;
+ list_iter->next->next = NULL;
+ return *list_p;
+}
+
unsigned commit_list_count(const struct commit_list *l)
{
unsigned c = 0;
diff --git a/commit.h b/commit.h
index b6ad8f3..17ae5e5 100644
--- a/commit.h
+++ b/commit.h
@@ -53,6 +53,8 @@ int find_commit_subject(const char *commit_buffer, const char **subject);
struct commit_list *commit_list_insert(struct commit *item,
struct commit_list **list);
+struct commit_list *commit_list_insert_end(struct commit *item,
+ struct commit_list **list);
struct commit_list **commit_list_append(struct commit *commit,
struct commit_list **next);
unsigned commit_list_count(const struct commit_list *l);
--
1.8.0
^ permalink raw reply related
* Re: Requirements for integrating a new git subcommand
From: Michael J Gruber @ 2012-11-23 9:13 UTC (permalink / raw)
To: esr; +Cc: Shawn Pearce, git
In-Reply-To: <20121122221107.GA16069@thyrsus.com>
Eric S. Raymond venit, vidit, dixit 22.11.2012 23:11:
> Shawn Pearce <spearce@spearce.org>:
>> [Lots of helpful stuff ended by]
>>> 4. How does "git help" work? That is, how is a subcommand expected
>>> to know when it is being called to export its help text?
>>
>> IIRC "git help foo" runs "man git-foo".
>
> OK, that makes sense.
>
>>> 5. I don't see any extensions written in Python. Are there any special
>>> requirements or exclusions for Python scripts?
>>
>> Nope, it just has to be executable. We don't have any current Python
>> code. IIRC the last Python code was the implementation of
>> git-merge-recursive, which was ported to C many years ago. We avoid
>> Python because it is not on every platform where Git is installed. Yes
>> Python is very portable and can be installed in many places, but we
>> prefer not to make it a requirement.
>
> I find that odd. You avoid Python but use shellscripts? *blink*
>
> One would think shellscripts were a much more serious portability problem.
Different versions of python can be a mess to deal with, also, at least
with respect to standard modules being "standard" or not for a specific
version.
In any case, the point is that we try to avoid *additional*
dependencies. Shell and perl are given with the status quo.
That being said, we also have remote helpers in python. The testsuite
can run tests depending on the availability of python.
Regarding git-weave, I'm wondering (without having looked at the code)
how this relates to git-archiv and git-fast-import/export, i.e. how much
this leverages existing infrastructure rather than reinventing the
wheel. Do your "trees" correspond to a "git tree"?
Again, without having looked at the code, it seems to me that exploding
blob and tree objects might give you a structure not much unlike
weave's, and your instruction sheet resembles that of fast-import quite
a bit (plus date fill-in etc.).
One could even dream about implementing this as a remote helper instead...
Michael
^ permalink raw reply
* Re: Requirements for integrating a new git subcommand
From: Peter Krefting @ 2012-11-23 9:27 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121122053012.GA17265@thyrsus.com>
Eric S. Raymond:
> git-weave(1)
> Yes, there are scripts in contrib that do similar things.
I was just about to say that the import direction of this seems to
fill the same need as contrib/fast-import/import-directories.perl that
I submitted a few years back.
Your version seems only to be able to import a linear history,
however, my tool does support creating merge commits (basically, the
history I had to import was very messy and contained a lot of snapshot
directories having been worked on in parallel).
> (b) I am shipping it with a functional test,
Hmm, indeed. I have been thinking of trying to wrap up the test suite
I have locally into something that could work within the Git testing
framework, but haven't found the time to or energy for so far.
Anyway, my sentiment is that if you can add support for merges in you
weave tool, then I am very much for removing my old script from the
repository.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH 0/8] fix git-config with duplicate variable entries
From: Joachim Schmitz @ 2012-11-23 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vehjm20yu.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
...
> Not exactly. There are three classes of people:
>
> - wrote scripts using --get; found out that --get barfs if you feed
> two or more of the same, and have long learned to accept it as a
> limitation and adjusted their configuration files to avoid it.
> They have been doing just fine and wouldn't benefit from this
> series at all.
>
> - wrote scripts using --get, relying on it barfing if fed zero
> (i.e. missing) or two or more (i.e. ambiguous), perhaps a way to
> keep their configuration files (arguably unnecessarily) clean.
> They are directly harmed by this series.
>
> - wrote scripts using --get-all and did the last-one-wins
> themselves. They wouldn't benefit directly from this series,
> unless they are willing to spend a bit of time to remove their
> own last-one-wins logic and replace --get-all with --get (but the
> same effort is needed to migrate to --get-one).
>
> - wanted to write scripts using --get, but after finding out that
> it barfs if you feed two, gave up emulating the internal, without
> realizing that they could do so with --get-all. They can now
> write their scripts without using --get-all.
There are three classes ofpeople: those that can count and those that can't
Sorry could not resist ;-)
^ permalink raw reply
* remote helper and relative local paths
From: Max Horn @ 2012-11-23 11:02 UTC (permalink / raw)
To: git
I noticed a problem with remote helpers which is mainly about convenience, but still annoying enough that I wish it could be resolved; but I'd like some input on what the proper way would be...
Here is the issue: cloning with relative paths is problematic (if not broken) when using remote-helpers, unless one is willing to dive into some (IMHO) gross hacking... To demonstrate what I mean, first consider that cloning a local git repo using relative paths works fine: If the parent dir contains a git repository "git-repo", this works:
$ git clone ../git-repo git-clone
Cloning into 'git-clone'...
done.
$ cd git-clone && git pull
Current branch master is up to date.
$
But when doing the same with a remote helper, it doesn't work; or rather, the initial cloning might work, but we end up with a broken remote.origin.url, as that still contains the relative path, but it no longer can be resolved since the PWD changed. E.g. here is an example using felipe's remote-hg:
$ git clone hg::../hg-repo git-clone
Cloning into 'git-clone'...
$ cd git-clone && git pull
Traceback (most recent call last):
[...]
mercurial.error.RepoError: repository ../hg-repo not found
$
One problem here is that git cannot resolve the local path in "hg::../hg-repo", because this URL is opaque for git, it's a black-box. Hence the code in "git clone" that would normally take care of this (specifically, get_repo_path() in builtin/clone.c) does not get applied.
Now, it is not difficult to resolve a relative path, and so a remote helper can do this -- but we only can do this while cloning (and then have to store the absolute path / the new URL), because later on, crucial information (the PWD at the time of cloning) is not available anymore.
So I made a hack that does this: In the remote helper, if the URL looks like a local path, and points to a directory containing a .hg subdir (or some variation of that), translate it into an absolute path. Then (and that is the part I feel bad about) invoke
git config remote.REPOS_ALIAS.url hg::the_computed_absolute_path
This works, but feels like a gross hack to me. In particular, as Felipe pointed out to me: While git is setting the remote.origin.url before invoking the remote helper right now, there is no guarantee for that (at least none that I am aware of).
So, is there a better way to achieve this that I am overlooking? Or does what I am doing actually seem fine? Or should there be a change to git itself (e.g. a revision to the remote-helper protocol) that helps to take care of that? And how should that look?
One simple idea for the last option would be to add a "sanitize" capability to remote-helpers, which takes a repository URL, and returns a sanitized version, where e.g. local paths have been resolved, and then "git clone" would make use of that to set the remote URL right. But perhaps I am overcomplicating things?
Cheers,
Max
^ permalink raw reply
* [PATCH v2] Completion must sort before using uniq
From: Marc Khouzam @ 2012-11-23 11:17 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, SZEDER Gábor
In-Reply-To: <CAMP44s3qpr11JXi-znddAH2BWYbM_kp+nZnTa8CQgCzrBmfzmA@mail.gmail.com>
The user can be presented with invalid completion results
when trying to complete a 'git checkout' command. This can happen
when using a branch name prefix that matches multiple remote branches.
For example if available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remotes/origin/maint
remotes/origin/master
When performing completion on 'git checkout ma' the user will be
given the choices:
maint
master
However, 'git checkout maint' will fail in this case, although
completion previously said 'maint' was valid.
Furthermore, when performing completion on 'git checkout mai',
no choices will be suggested. So, the user is first told that the
branch name 'maint' is valid, but when trying to complete 'mai'
into 'maint', that completion is no longer valid.
The completion results should never propose 'maint' as a valid
branch name, since 'git checkout' will refuse it.
The reason for this bug is that the uniq program only
works with sorted input. The man page states
"uniq prints the unique lines in a sorted file".
When __git_refs uses the guess heuristic employed by checkout for
tracking branches it wants to consider remote branches but only if
the branch name is unique. To do that, it calls 'uniq -u'. However
the input given to 'uniq -u' is not sorted.
Therefore, in the above example, when dealing with 'git checkout ma',
"__git_refs '' 1" will find the following list:
master
maint
master
maint
master
which, when passed to 'uniq -u' will remain the same. Therefore
'maint' will be wrongly suggested as a valid option.
When dealing with 'git checkout mai', the list will be:
maint
maint
which happens to be sorted and will be emptied by 'uniq -u',
properly ignoring 'maint'.
A solution for preventing the completion script from suggesting
such invalid branch names is to first call 'sort' and then 'uniq -u'.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
---
>> The solution is to first call 'sort' and then 'uniq -u'.
>
> The solution to what? This seems to be the right thing indeed, but you
> don't explain what is the actual problem that is being solved. What
> does the user experience? What would (s)he experience after the patch?
I have re-worked the commit message to be more clear about the user
impacts.
Thanks for the feedback.
Marc
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bc0657a..85ae419 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,7 +321,7 @@ __git_refs ()
if [[ "$ref" == "$cur"* ]]; then
echo "$ref"
fi
- done | uniq -u
+ done | sort | uniq -u
fi
return
fi
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* Re: [PATCH v2] Completion must sort before using uniq
From: Felipe Contreras @ 2012-11-23 11:34 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git, SZEDER Gábor
In-Reply-To: <CAFj1UpHAqrNvpF+HAxJUPiWAiHbCn=7r1GDw3iMKy8FDW_-D_A@mail.gmail.com>
Hi,
Mostly cosmetic suggestions, but it looks OK to me.
On Fri, Nov 23, 2012 at 12:17 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> The user can be presented with invalid completion results
> when trying to complete a 'git checkout' command. This can happen
> when using a branch name prefix that matches multiple remote branches.
Space here.
> For example if available branches are:
For example; <- separation
> master
> remotes/GitHub/maint
> remotes/GitHub/master
> remotes/origin/maint
> remotes/origin/master
>
> When performing completion on 'git checkout ma' the user will be
> given the choices:
> maint
> master
Space.
> However, 'git checkout maint' will fail in this case, although
> completion previously said 'maint' was valid.
Space (or continue paragraph).
> Furthermore, when performing completion on 'git checkout mai',
> no choices will be suggested. So, the user is first told that the
> branch name 'maint' is valid, but when trying to complete 'mai'
> into 'maint', that completion is no longer valid.
>
> The completion results should never propose 'maint' as a valid
> branch name, since 'git checkout' will refuse it.
With this explanation the patch looks good to me.
> The reason for this bug is that the uniq program only
> works with sorted input. The man page states
> "uniq prints the unique lines in a sorted file".
>
> When __git_refs uses the guess heuristic employed by checkout for
> tracking branches it wants to consider remote branches but only if
> the branch name is unique. To do that, it calls 'uniq -u'. However
> the input given to 'uniq -u' is not sorted.
>
> Therefore, in the above example, when dealing with 'git checkout ma',
> "__git_refs '' 1" will find the following list:
> master
> maint
> master
> maint
> master
Space.
> which, when passed to 'uniq -u' will remain the same. Therefore
> 'maint' will be wrongly suggested as a valid option.
Space.
> When dealing with 'git checkout mai', the list will be:
> maint
> maint
Space.
> which happens to be sorted and will be emptied by 'uniq -u',
> properly ignoring 'maint'.
>
> A solution for preventing the completion script from suggesting
> such invalid branch names is to first call 'sort' and then 'uniq -u'.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* RE: [PATCH] Completion must sort before using uniq
From: Joachim Schmitz @ 2012-11-23 12:15 UTC (permalink / raw)
To: 'Marc Khouzam', git; +Cc: szeder, felipe.contreras
In-Reply-To: <CAFj1UpEMKq9zH3nbLwYrNZRmd52_KEcN5BBrzGg2jxCzd+fsbA@mail.gmail.com>
Re-adding git@vger...
> From: Marc Khouzam [mailto:marc.khouzam@gmail.com]
> Sent: Friday, November 23, 2012 11:51 AM
> To: Joachim Schmitz
> Cc: szeder@ira.uka.de; felipe.contreras@gmail.com
> Subject: Re: [PATCH] Completion must sort before using uniq
>
> On Fri, Nov 23, 2012 at 3:10 AM, Joachim Schmitz
> <jojo@schmitz-digital.de> wrote:
> > Marc Khouzam wrote:
> >> The uniq program only works with sorted input. The man page states
> >> "uniq prints the unique lines in a sorted file".
> > ...
> >> --- a/contrib/completion/git-completion.bash
> >> +++ b/contrib/completion/git-completion.bash
> >> @@ -321,7 +321,7 @@ __git_refs ()
> >> if [[ "$ref" == "$cur"* ]]; then
> >> echo "$ref"
> >> fi
> >> - done | uniq -u
> >> + done | sort | uniq -u
> >
> > Is 'sort -u' not universally available and sufficient here? It is POSIX
> > at least:
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html
>
> "-u Unique: suppress all but one in each set of lines having equal
> keys. If used with the -c option, check that there are no lines with
> duplicate keys, in addition to checking that the input file is
> sorted."
>
> What the code aims to do is to only show lines that are not
> duplicated. 'sort -u' would still output one line for each duplicated
> one. It seems 'sort -u' is the equivalent of 'sort | uniq' but won't
> replace 'sort | uniq -u'.
I can't see the difference and in fact don't understand uniq's -u option al all
Linux man pages say: "only print unique lines", but that is what uniq does by default anyway?!?
> Is 'sort | uniq -u' not POSIX?
It is. It is one process more though.
Bye, Jojo
^ permalink raw reply
* Re: [PATCH] Completion must sort before using uniq
From: Sascha Cunz @ 2012-11-23 12:26 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: 'Marc Khouzam', git, szeder, felipe.contreras
In-Reply-To: <003b01cdc974$4cdd1900$e6974b00$@schmitz-digital.de>
> I can't see the difference and in fact don't understand uniq's -u option al
> all Linux man pages say: "only print unique lines", but that is what uniq
> does by default anyway?!?
>From the german translation of uniq's man-page, you can deduct that "only
print unique lines" actually means: "print lines that are _not repeated_ in
the input".
A short test confirms that. i.e.:
printf "a\nb\nb\nc\n" | uniq -u
gives:
a
c
Sascha
^ permalink raw reply
* RE: [PATCH] Completion must sort before using uniq
From: Joachim Schmitz @ 2012-11-23 12:36 UTC (permalink / raw)
To: 'Sascha Cunz'
Cc: 'Marc Khouzam', git, szeder, felipe.contreras
In-Reply-To: <2630847.8aaR79v5Od@blacky>
> From: Sascha Cunz [mailto:sascha-ml@babbelbox.org]
> Sent: Friday, November 23, 2012 1:26 PM
> To: Joachim Schmitz
> Cc: 'Marc Khouzam'; git@vger.kernel.org; szeder@ira.uka.de; felipe.contreras@gmail.com
> Subject: Re: [PATCH] Completion must sort before using uniq
>
> > I can't see the difference and in fact don't understand uniq's -u option al
> > all Linux man pages say: "only print unique lines", but that is what uniq
> > does by default anyway?!?
>
> From the german translation of uniq's man-page, you can deduct that "only
> print unique lines" actually means: "print lines that are _not repeated_ in
> the input".
>
> A short test confirms that. i.e.:
>
> printf "a\nb\nb\nc\n" | uniq -u
>
> gives:
> a
> c
Ah, OK, then I rest my case. Sorry for the noise.
^ permalink raw reply
* Re: [PATCH] gitk tag delete/rename support
From: Ramkumar Ramachandra @ 2012-11-23 12:38 UTC (permalink / raw)
To: Leon KUKOVEC; +Cc: git, Junio C Hamano
In-Reply-To: <1353649899-15641-1-git-send-email-leon.kukovec@gmail.com>
Leon KUKOVEC wrote:
> ---
> [...]
Commit message and signoff?
Ram
^ permalink raw reply
* [PATCH v3] Completion must sort before using uniq
From: Marc Khouzam @ 2012-11-23 14:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor, Felipe Contreras
In-Reply-To: <CAMP44s2bMub6T1YcUfsYWPQFU1bY4iU1WfSf+jFa7jSXAKTNaw@mail.gmail.com>
The user can be presented with invalid completion results
when trying to complete a 'git checkout' command. This can happen
when using a branch name prefix that matches multiple remote branches.
For example, if available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remotes/origin/maint
remotes/origin/master
When performing completion on 'git checkout ma' the user will be
given the choices:
maint
master
However, 'git checkout maint' will fail in this case, although
completion previously said 'maint' was valid. Furthermore, when
performing completion on 'git checkout mai', no choices will be
suggested. So, the user is first told that the branch name
'maint' is valid, but when trying to complete 'mai' into 'maint',
that completion is no longer valid.
The completion results should never propose 'maint' as a valid
branch name, since 'git checkout' will refuse it.
The reason for this bug is that the uniq program only
works with sorted input. The man page states
"uniq prints the unique lines in a sorted file".
When __git_refs uses the guess heuristic employed by checkout for
tracking branches it wants to consider remote branches but only if
the branch name is unique. To do that, it calls 'uniq -u'. However
the input given to 'uniq -u' is not sorted.
Therefore, in the above example, when dealing with 'git checkout ma',
"__git_refs '' 1" will find the following list:
master
maint
master
maint
master
which, when passed to 'uniq -u' will remain the same. Therefore
'maint' will be wrongly suggested as a valid option.
When dealing with 'git checkout mai', the list will be:
maint
maint
which happens to be sorted and will be emptied by 'uniq -u',
properly ignoring 'maint'.
A solution for preventing the completion script from suggesting
such invalid branch names is to first call 'sort' and then 'uniq -u'.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
---
> Mostly cosmetic suggestions, but it looks OK to me.
Thanks for the suggestions, I updated the commit message.
> With this explanation the patch looks good to me.
Thanks for the quick review.
Marc
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bc0657a..85ae419 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,7 +321,7 @@ __git_refs ()
if [[ "$ref" == "$cur"* ]]; then
echo "$ref"
fi
- done | uniq -u
+ done | sort | uniq -u
fi
return
fi
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* Re: git bash does not access drive f:
From: Heiko Voigt @ 2012-11-23 15:31 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9Ae46PNRex9QrEy9gTgqAbn8KUFifmxQU4s5K5mDDmDZQ@mail.gmail.com>
Hi,
On Thu, Nov 22, 2012 at 08:07:55AM +0100, Angelo Borsotti wrote:
> I have attached an external disc, which appears on Windows as drive f:
> in Windows Explorer.
> Right-clicking on it displays a context menu showing (among other
> items) Git Init Here, Git Gui and
> Git Bash. The first two work properly on that drive.
> However, the git bash does not. Not even the one that is run from the icon:
>
> $ cd f:
> sh.exe": cd: f:: No such file or directory
>
>
> Is there any way to make it access drive f?
Try using the environment variable MSYS_WATCH_FSTAB=YesPlease.
We have an optimization in msys that does not update the virtually
mounted folders and makes msys executable startups faster. I had similar
issues with mounted disk images.
The other alternative: After having the external disc mounted logout and
login again that AFAIR that should also help.
Cheers Heiko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox