Re: [RFC] git rebase -s ours

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

 



On Sat, Mar 01, 2008 at 12:17:16PM +0100, Mike Hommey wrote:

> What do you think git rebase -s ours should be considering as "ours"?
> If I'm not mistaken, at the moment, "ours" stands for "upstream", which
> is kind of confusing...

Sort of. It actually works as "what is in the working tree is fine" so
it ends up not applying _any_ commits. In other words,

  git rebase --strategy=ours upstream

is equivalent to

  git reset --hard upstream

So I think the current behavior is nonsensical, and I assume nobody uses
it.

OTOH, what exactly are you trying to accomplish? If you have "ours" mean
"always take the rebased content", then aren't you stomping on original
commits? You might mean something like "do a regular 3-way merge, and
for every textual conflict, choose the rebased content". That at least
makes some sense, but I suspect it will produce uncompilable results in
most cases.

What I am getting at is: what 'ours' should mean in a rebase depends on
how it can usefully be used in a workflow. Do you have a workflow in
mind?

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

  Powered by Linux