git merge/rebase ref -P ref

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

git merge/rebase ref -P ref

ryenus ◇
The inverted meaning of {ours,theirs} for rebase could be very
confusing to some, especially to new uses, for me every time I
merge/rebase I need to think about it to make sure I've made it right.

What about making it more intuitive?

We can and a new option (like '-P') for people to specify the
preferred branch/ref by it's name.

E.g. assume I have two branches, namely 'dev' and 'exp', and I prefer
the changeset on the 'dev' branch when I merge or rebase, so that I
can do it with

# using merge
git checkout dev
git merge exp -P dev

OR

# using rebase
git checkout exp
git rebase dev -P dev
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: git merge/rebase ref -P ref

Junio C Hamano
ryenus <[hidden email]> writes:

> The inverted meaning of {ours,theirs} for rebase could be very
> confusing to some, especially to new uses, for me every time I
> merge/rebase I need to think about it to make sure I've made it right.

The key point to remember is "git rebase origin master" is *not*
about integrating other people's changes to your work.  It is a way
to replay your work on top of others' work.

When I try to rebase a topic, e.g.

    git checkout jc/format-patch
    git rebase 8ee3860
   
The conflicts in pretty.c looks like this:

    <<<<<<< HEAD
    static const char *show_ident_date(const struct ident_split *ident,
                                       enum date_mode mode)
    {
    ...
            return show_date(date, tz, mode);
    =======
    static int is_current_user(const struct pretty_print_context *pp,
                               const char *email, size_t emaillen,
                               const char *name, size_t namelen)
    {
    ...
                    !memcmp(myname, name, namelen));
    >>>>>>> format-patch: --inline-single
    }

We are replaying the commits on "jc/format-patch" topic on a history
that leads to 8ee3860, and the line ">>>>>" shows what commit we are
replaying

    $ git log --oneline 8ee3860..jc/format-patch
    be1a07f format-patch: --inline-single
    47d6c5f format-patch: rename "no_inline" field

On the other hand, when I try to do the same integration with a
merge, e.g.

    git checkout 8ee3860
    git merge jc/format-patch

We would see the same conflicts like this:

    <<<<<<< HEAD
    static const char *show_ident_date(const struct ident_split *ident,
                                       enum date_mode mode)
    {
    ...
            return show_date(date, tz, mode);
    =======
    static int is_current_user(const struct pretty_print_context *pp,
                               const char *email, size_t emaillen,
                               const char *name, size_t namelen)
    {
    ...
                    !memcmp(myname, name, namelen));
    >>>>>>> jc/format-patch
    }

Again, the name of the branch that is merged appears on ">>>>>"
line.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html