2007-07-14 23:14:45 +00:00
|
|
|
#include "builtin.h"
|
2005-04-17 19:18:17 +00:00
|
|
|
#include "cache.h"
|
2005-04-18 18:39:48 +00:00
|
|
|
#include "commit.h"
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
#include "refs.h"
|
|
|
|
#include "diff.h"
|
|
|
|
#include "revision.h"
|
2008-10-02 12:59:19 +00:00
|
|
|
#include "parse-options.h"
|
2005-04-17 19:18:17 +00:00
|
|
|
|
2008-07-30 05:04:14 +00:00
|
|
|
static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
|
2006-06-29 13:16:46 +00:00
|
|
|
{
|
2008-07-30 05:04:14 +00:00
|
|
|
struct commit_list *result;
|
|
|
|
|
2014-10-30 19:20:44 +00:00
|
|
|
result = get_merge_bases_many_dirty(rev[0], rev_nr - 1, rev + 1);
|
2006-06-29 13:16:46 +00:00
|
|
|
|
|
|
|
if (!result)
|
|
|
|
return 1;
|
|
|
|
|
2005-08-24 04:08:59 +00:00
|
|
|
while (result) {
|
2015-11-10 02:22:28 +00:00
|
|
|
printf("%s\n", oid_to_hex(&result->item->object.oid));
|
2005-08-24 04:08:59 +00:00
|
|
|
if (!show_all)
|
|
|
|
return 0;
|
2006-06-29 13:16:46 +00:00
|
|
|
result = result->next;
|
2005-08-24 04:08:59 +00:00
|
|
|
}
|
2006-06-29 13:16:46 +00:00
|
|
|
|
2005-08-24 04:08:59 +00:00
|
|
|
return 0;
|
2005-04-17 19:18:17 +00:00
|
|
|
}
|
|
|
|
|
2008-10-02 12:59:19 +00:00
|
|
|
static const char * const merge_base_usage[] = {
|
2015-01-13 07:44:47 +00:00
|
|
|
N_("git merge-base [-a | --all] <commit> <commit>..."),
|
|
|
|
N_("git merge-base [-a | --all] --octopus <commit>..."),
|
2012-08-20 12:32:22 +00:00
|
|
|
N_("git merge-base --independent <commit>..."),
|
2012-09-11 18:35:26 +00:00
|
|
|
N_("git merge-base --is-ancestor <commit> <commit>"),
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
N_("git merge-base --fork-point <ref> [<commit>]"),
|
2008-10-02 12:59:19 +00:00
|
|
|
NULL
|
|
|
|
};
|
2005-08-24 04:08:59 +00:00
|
|
|
|
2008-07-29 05:42:53 +00:00
|
|
|
static struct commit *get_commit_reference(const char *arg)
|
|
|
|
{
|
2017-02-21 23:47:36 +00:00
|
|
|
struct object_id revkey;
|
2008-07-29 05:42:53 +00:00
|
|
|
struct commit *r;
|
|
|
|
|
2017-02-21 23:47:36 +00:00
|
|
|
if (get_oid(arg, &revkey))
|
2008-07-29 05:42:53 +00:00
|
|
|
die("Not a valid object name %s", arg);
|
Convert lookup_commit* to struct object_id
Convert lookup_commit, lookup_commit_or_die,
lookup_commit_reference, and lookup_commit_reference_gently to take
struct object_id arguments.
Introduce a temporary in parse_object buffer in order to convert this
function. This is required since in order to convert parse_object and
parse_object_buffer, lookup_commit_reference_gently and
lookup_commit_or_die would need to be converted. Not introducing a
temporary would therefore require that lookup_commit_or_die take a
struct object_id *, but lookup_commit would take unsigned char *,
leaving a confusing and hard-to-use interface.
parse_object_buffer will lose this temporary in a later patch.
This commit was created with manual changes to commit.c, commit.h, and
object.c, plus the following semantic patch:
@@
expression E1, E2;
@@
- lookup_commit_reference_gently(E1.hash, E2)
+ lookup_commit_reference_gently(&E1, E2)
@@
expression E1, E2;
@@
- lookup_commit_reference_gently(E1->hash, E2)
+ lookup_commit_reference_gently(E1, E2)
@@
expression E1;
@@
- lookup_commit_reference(E1.hash)
+ lookup_commit_reference(&E1)
@@
expression E1;
@@
- lookup_commit_reference(E1->hash)
+ lookup_commit_reference(E1)
@@
expression E1;
@@
- lookup_commit(E1.hash)
+ lookup_commit(&E1)
@@
expression E1;
@@
- lookup_commit(E1->hash)
+ lookup_commit(E1)
@@
expression E1, E2;
@@
- lookup_commit_or_die(E1.hash, E2)
+ lookup_commit_or_die(&E1, E2)
@@
expression E1, E2;
@@
- lookup_commit_or_die(E1->hash, E2)
+ lookup_commit_or_die(E1, E2)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-06 22:10:10 +00:00
|
|
|
r = lookup_commit_reference(&revkey);
|
2008-07-29 05:42:53 +00:00
|
|
|
if (!r)
|
|
|
|
die("Not a valid commit name %s", arg);
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2013-12-30 19:37:49 +00:00
|
|
|
static int handle_independent(int count, const char **args)
|
2010-08-17 07:01:15 +00:00
|
|
|
{
|
|
|
|
struct commit_list *revs = NULL;
|
|
|
|
struct commit_list *result;
|
|
|
|
int i;
|
|
|
|
|
2013-12-30 19:37:49 +00:00
|
|
|
for (i = count - 1; i >= 0; i--)
|
|
|
|
commit_list_insert(get_commit_reference(args[i]), &revs);
|
|
|
|
|
|
|
|
result = reduce_heads(revs);
|
|
|
|
if (!result)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
while (result) {
|
2015-11-10 02:22:28 +00:00
|
|
|
printf("%s\n", oid_to_hex(&result->item->object.oid));
|
2013-12-30 19:37:49 +00:00
|
|
|
result = result->next;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int handle_octopus(int count, const char **args, int show_all)
|
|
|
|
{
|
|
|
|
struct commit_list *revs = NULL;
|
|
|
|
struct commit_list *result;
|
|
|
|
int i;
|
2010-08-17 07:01:54 +00:00
|
|
|
|
|
|
|
for (i = count - 1; i >= 0; i--)
|
2010-08-17 07:01:15 +00:00
|
|
|
commit_list_insert(get_commit_reference(args[i]), &revs);
|
2010-08-17 07:01:54 +00:00
|
|
|
|
2013-12-30 19:58:54 +00:00
|
|
|
result = reduce_heads(get_octopus_merge_bases(revs));
|
2010-08-17 07:01:15 +00:00
|
|
|
|
|
|
|
if (!result)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
while (result) {
|
2015-11-10 02:22:28 +00:00
|
|
|
printf("%s\n", oid_to_hex(&result->item->object.oid));
|
2010-08-17 07:01:15 +00:00
|
|
|
if (!show_all)
|
|
|
|
return 0;
|
|
|
|
result = result->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-08-30 21:52:20 +00:00
|
|
|
static int handle_is_ancestor(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
struct commit *one, *two;
|
|
|
|
|
|
|
|
if (argc != 2)
|
|
|
|
die("--is-ancestor takes exactly two commits");
|
|
|
|
one = get_commit_reference(argv[0]);
|
|
|
|
two = get_commit_reference(argv[1]);
|
|
|
|
if (in_merge_bases(one, two))
|
|
|
|
return 0;
|
|
|
|
else
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
struct rev_collect {
|
|
|
|
struct commit **commit;
|
|
|
|
int nr;
|
|
|
|
int alloc;
|
|
|
|
unsigned int initial : 1;
|
|
|
|
};
|
|
|
|
|
2017-02-21 23:47:36 +00:00
|
|
|
static void add_one_commit(struct object_id *oid, struct rev_collect *revs)
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
{
|
|
|
|
struct commit *commit;
|
|
|
|
|
2017-02-21 23:47:36 +00:00
|
|
|
if (is_null_oid(oid))
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
return;
|
|
|
|
|
Convert lookup_commit* to struct object_id
Convert lookup_commit, lookup_commit_or_die,
lookup_commit_reference, and lookup_commit_reference_gently to take
struct object_id arguments.
Introduce a temporary in parse_object buffer in order to convert this
function. This is required since in order to convert parse_object and
parse_object_buffer, lookup_commit_reference_gently and
lookup_commit_or_die would need to be converted. Not introducing a
temporary would therefore require that lookup_commit_or_die take a
struct object_id *, but lookup_commit would take unsigned char *,
leaving a confusing and hard-to-use interface.
parse_object_buffer will lose this temporary in a later patch.
This commit was created with manual changes to commit.c, commit.h, and
object.c, plus the following semantic patch:
@@
expression E1, E2;
@@
- lookup_commit_reference_gently(E1.hash, E2)
+ lookup_commit_reference_gently(&E1, E2)
@@
expression E1, E2;
@@
- lookup_commit_reference_gently(E1->hash, E2)
+ lookup_commit_reference_gently(E1, E2)
@@
expression E1;
@@
- lookup_commit_reference(E1.hash)
+ lookup_commit_reference(&E1)
@@
expression E1;
@@
- lookup_commit_reference(E1->hash)
+ lookup_commit_reference(E1)
@@
expression E1;
@@
- lookup_commit(E1.hash)
+ lookup_commit(&E1)
@@
expression E1;
@@
- lookup_commit(E1->hash)
+ lookup_commit(E1)
@@
expression E1, E2;
@@
- lookup_commit_or_die(E1.hash, E2)
+ lookup_commit_or_die(&E1, E2)
@@
expression E1, E2;
@@
- lookup_commit_or_die(E1->hash, E2)
+ lookup_commit_or_die(E1, E2)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-06 22:10:10 +00:00
|
|
|
commit = lookup_commit(oid);
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
if (!commit ||
|
|
|
|
(commit->object.flags & TMP_MARK) ||
|
|
|
|
parse_commit(commit))
|
|
|
|
return;
|
|
|
|
|
|
|
|
ALLOC_GROW(revs->commit, revs->nr + 1, revs->alloc);
|
|
|
|
revs->commit[revs->nr++] = commit;
|
|
|
|
commit->object.flags |= TMP_MARK;
|
|
|
|
}
|
|
|
|
|
2017-02-21 23:47:32 +00:00
|
|
|
static int collect_one_reflog_ent(struct object_id *ooid, struct object_id *noid,
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
const char *ident, unsigned long timestamp,
|
|
|
|
int tz, const char *message, void *cbdata)
|
|
|
|
{
|
|
|
|
struct rev_collect *revs = cbdata;
|
|
|
|
|
|
|
|
if (revs->initial) {
|
|
|
|
revs->initial = 0;
|
2017-02-21 23:47:36 +00:00
|
|
|
add_one_commit(ooid, revs);
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
}
|
2017-02-21 23:47:36 +00:00
|
|
|
add_one_commit(noid, revs);
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int handle_fork_point(int argc, const char **argv)
|
|
|
|
{
|
2017-02-21 23:47:36 +00:00
|
|
|
struct object_id oid;
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
char *refname;
|
|
|
|
const char *commitname;
|
|
|
|
struct rev_collect revs;
|
|
|
|
struct commit *derived;
|
|
|
|
struct commit_list *bases;
|
|
|
|
int i, ret = 0;
|
|
|
|
|
2017-02-21 23:47:36 +00:00
|
|
|
switch (dwim_ref(argv[0], strlen(argv[0]), oid.hash, &refname)) {
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
case 0:
|
|
|
|
die("No such ref: '%s'", argv[0]);
|
|
|
|
case 1:
|
|
|
|
break; /* good */
|
|
|
|
default:
|
|
|
|
die("Ambiguous refname: '%s'", argv[0]);
|
|
|
|
}
|
|
|
|
|
|
|
|
commitname = (argc == 2) ? argv[1] : "HEAD";
|
2017-02-21 23:47:36 +00:00
|
|
|
if (get_oid(commitname, &oid))
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
die("Not a valid object name: '%s'", commitname);
|
|
|
|
|
Convert lookup_commit* to struct object_id
Convert lookup_commit, lookup_commit_or_die,
lookup_commit_reference, and lookup_commit_reference_gently to take
struct object_id arguments.
Introduce a temporary in parse_object buffer in order to convert this
function. This is required since in order to convert parse_object and
parse_object_buffer, lookup_commit_reference_gently and
lookup_commit_or_die would need to be converted. Not introducing a
temporary would therefore require that lookup_commit_or_die take a
struct object_id *, but lookup_commit would take unsigned char *,
leaving a confusing and hard-to-use interface.
parse_object_buffer will lose this temporary in a later patch.
This commit was created with manual changes to commit.c, commit.h, and
object.c, plus the following semantic patch:
@@
expression E1, E2;
@@
- lookup_commit_reference_gently(E1.hash, E2)
+ lookup_commit_reference_gently(&E1, E2)
@@
expression E1, E2;
@@
- lookup_commit_reference_gently(E1->hash, E2)
+ lookup_commit_reference_gently(E1, E2)
@@
expression E1;
@@
- lookup_commit_reference(E1.hash)
+ lookup_commit_reference(&E1)
@@
expression E1;
@@
- lookup_commit_reference(E1->hash)
+ lookup_commit_reference(E1)
@@
expression E1;
@@
- lookup_commit(E1.hash)
+ lookup_commit(&E1)
@@
expression E1;
@@
- lookup_commit(E1->hash)
+ lookup_commit(E1)
@@
expression E1, E2;
@@
- lookup_commit_or_die(E1.hash, E2)
+ lookup_commit_or_die(&E1, E2)
@@
expression E1, E2;
@@
- lookup_commit_or_die(E1->hash, E2)
+ lookup_commit_or_die(E1, E2)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-06 22:10:10 +00:00
|
|
|
derived = lookup_commit_reference(&oid);
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
memset(&revs, 0, sizeof(revs));
|
|
|
|
revs.initial = 1;
|
|
|
|
for_each_reflog_ent(refname, collect_one_reflog_ent, &revs);
|
|
|
|
|
2017-02-21 23:47:36 +00:00
|
|
|
if (!revs.nr && !get_oid(refname, &oid))
|
|
|
|
add_one_commit(&oid, &revs);
|
2016-10-12 20:10:40 +00:00
|
|
|
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
for (i = 0; i < revs.nr; i++)
|
|
|
|
revs.commit[i]->object.flags &= ~TMP_MARK;
|
|
|
|
|
2014-10-30 19:20:44 +00:00
|
|
|
bases = get_merge_bases_many_dirty(derived, revs.nr, revs.commit);
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* There should be one and only one merge base, when we found
|
|
|
|
* a common ancestor among reflog entries.
|
|
|
|
*/
|
|
|
|
if (!bases || bases->next) {
|
|
|
|
ret = 1;
|
|
|
|
goto cleanup_return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* And the found one must be one of the reflog entries */
|
|
|
|
for (i = 0; i < revs.nr; i++)
|
|
|
|
if (&bases->item->object == &revs.commit[i]->object)
|
|
|
|
break; /* found */
|
|
|
|
if (revs.nr <= i) {
|
|
|
|
ret = 1; /* not found */
|
|
|
|
goto cleanup_return;
|
|
|
|
}
|
|
|
|
|
2015-11-10 02:22:28 +00:00
|
|
|
printf("%s\n", oid_to_hex(&bases->item->object.oid));
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
|
|
|
|
cleanup_return:
|
|
|
|
free_commit_list(bases);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2007-01-09 08:50:02 +00:00
|
|
|
int cmd_merge_base(int argc, const char **argv, const char *prefix)
|
2005-04-17 19:18:17 +00:00
|
|
|
{
|
2008-07-30 05:04:14 +00:00
|
|
|
struct commit **rev;
|
|
|
|
int rev_nr = 0;
|
2007-01-09 08:50:02 +00:00
|
|
|
int show_all = 0;
|
2013-10-23 23:10:25 +00:00
|
|
|
int cmdmode = 0;
|
2005-04-17 19:18:17 +00:00
|
|
|
|
2008-10-02 12:59:19 +00:00
|
|
|
struct option options[] = {
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('a', "all", &show_all, N_("output all common ancestors")),
|
2013-10-23 23:10:25 +00:00
|
|
|
OPT_CMDMODE(0, "octopus", &cmdmode,
|
|
|
|
N_("find ancestors for a single n-way merge"), 'o'),
|
|
|
|
OPT_CMDMODE(0, "independent", &cmdmode,
|
|
|
|
N_("list revs not reachable from others"), 'r'),
|
|
|
|
OPT_CMDMODE(0, "is-ancestor", &cmdmode,
|
|
|
|
N_("is the first one ancestor of the other?"), 'a'),
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
OPT_CMDMODE(0, "fork-point", &cmdmode,
|
|
|
|
N_("find where <commit> forked from reflog of <ref>"), 'f'),
|
2008-10-02 12:59:19 +00:00
|
|
|
OPT_END()
|
|
|
|
};
|
2008-07-30 05:04:14 +00:00
|
|
|
|
2008-10-02 12:59:19 +00:00
|
|
|
git_config(git_default_config, NULL);
|
2009-05-23 18:53:12 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, options, merge_base_usage, 0);
|
2013-10-23 23:10:25 +00:00
|
|
|
|
|
|
|
if (cmdmode == 'a') {
|
|
|
|
if (argc < 2)
|
|
|
|
usage_with_options(merge_base_usage, options);
|
|
|
|
if (show_all)
|
|
|
|
die("--is-ancestor cannot be used with --all");
|
2012-08-30 21:52:20 +00:00
|
|
|
return handle_is_ancestor(argc, argv);
|
2013-10-23 23:10:25 +00:00
|
|
|
}
|
2010-08-17 07:01:15 +00:00
|
|
|
|
2013-10-23 23:10:25 +00:00
|
|
|
if (cmdmode == 'r' && show_all)
|
|
|
|
die("--independent cannot be used with --all");
|
|
|
|
|
2014-01-10 18:33:32 +00:00
|
|
|
if (cmdmode == 'o')
|
2013-12-30 19:37:49 +00:00
|
|
|
return handle_octopus(argc, argv, show_all);
|
2014-01-10 18:33:32 +00:00
|
|
|
|
|
|
|
if (cmdmode == 'r')
|
2013-12-30 19:37:49 +00:00
|
|
|
return handle_independent(argc, argv);
|
2013-10-23 23:10:25 +00:00
|
|
|
|
merge-base: teach "--fork-point" mode
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23 23:47:32 +00:00
|
|
|
if (cmdmode == 'f') {
|
|
|
|
if (argc < 1 || 2 < argc)
|
|
|
|
usage_with_options(merge_base_usage, options);
|
|
|
|
return handle_fork_point(argc, argv);
|
|
|
|
}
|
|
|
|
|
2013-10-23 23:10:25 +00:00
|
|
|
if (argc < 2)
|
|
|
|
usage_with_options(merge_base_usage, options);
|
2010-08-17 07:01:15 +00:00
|
|
|
|
2016-02-22 22:44:25 +00:00
|
|
|
ALLOC_ARRAY(rev, argc);
|
2008-10-02 12:59:19 +00:00
|
|
|
while (argc-- > 0)
|
|
|
|
rev[rev_nr++] = get_commit_reference(*argv++);
|
2008-07-30 05:04:14 +00:00
|
|
|
return show_merge_base(rev, rev_nr, show_all);
|
2005-04-17 19:18:17 +00:00
|
|
|
}
|