On Aug 6, 2014, at 10:11 PM, Nico Williams wrote:
> Nah. Sun managed this for decades without a hitch, and for products
> much larger than GCC. See above.
Ok. Ah, ok, perfect. I see how that method of working would cure the
cherry-pick and merge don’t work problem mentioned at the top of the
[ sorry for the dup ]
Begin forwarded message:
On Aug 6, 2014, at 12:44 PM, Nico Williams wrote:
> It's not a good idea to rebase a branch in a repo that others pull from.
Well, so rebase is then out, as I don’t want to rebase _my_ tree, I want to
rebase _the_ tree. Recall, I don’t want to ch
On Aug 1, 2014, at 4:40 PM, Nico Williams wrote:
> As for rebase, I still don't understand why it doesn't work for you.
http://git-scm.com/docs/git-rebase says:
Rebasing (or any other form of rewriting) a branch that others have based
work on is a bad idea
If you read stack-overflow, you wil
On Aug 6, 2014, at 8:43 AM, Jakub Narębski wrote:
>>> I gave a solution for git using branches and it works just fine. It
>>> retains the simple 3-point merge as well.
>
> It works for this simple case, but I think it has unfortunate potential
> to go silently wrong.
That just means that you wa
On Aug 1, 2014, at 1:50 PM, Jonathan Nieder wrote:
>
> And on the other hand a one-patch-at-a-time merge would
> try to apply X (with no effect, since it's already applied)
> and then try to apply the revert of X. The net effect would
> be to revert X from "master" (bad)!
On Aug 1, 2014, at 1:12 PM, Sam Vilain wrote:
> Git merge has a notion of discrete "merge strategies”.
> There's no particular reason that you couldn't implement a merge
> strategy which works more like SVN's approach, which essentially does an
> internal rebase and then commits the result.
Well
On Aug 1, 2014, at 1:02 PM, Jonathan Nieder wrote:
>
> Do you mean that "git merge" should be aware of what changes you have
> already cherry-picked?
Yes, it amounts to that.
> It isn't, and that's deliberate
Deliberate bugs are still bugs. In time, users will either wear you down until
you
On Aug 1, 2014, at 12:01 PM, Jakub Narębski wrote:
> It can work in Subversion because Subversion stores information about
> what was merged in (and this includes cherry-picks, or whatever it is
> named in svn) in svn:mergeinfo property. Git does not track what was
> merged in, instead it represen
On Aug 1, 2014, at 11:57 AM, Philip Oakley wrote:
> But that goes both ways, and is a philosophical issue about what is to be
> expected in various cases.
The problem is, users expect merge to merge. There isn’t a user that expects
it to scramble the source code, because the command is called
On Aug 1, 2014, at 12:22 PM, Nico Williams wrote:
> If you always rebase
I can’t use rebase unless you make rebase work with multiple users and pushing
pulling.--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On Aug 1, 2014, at 9:27 AM, Jakub Narębski wrote:
>
> Note that you should try to avoid cherry-picking, as they do not
> leave trace in the graph of revisions.
Fine, then I want a new command to merge in a change into my branch from
another branch and I want merge to account for the motion and
On Jul 31, 2014, at 7:43 PM, brian m. carlson
wrote:
>
> You're not the first person to be surprised by the way merge works.
I’m not the first, because the merge command is broken. Once fixed, I would be
happy to be the last. Until then, the bug remains unfixed. I’m sending the
mail to pet
Cherry picking doesn’t work as well as it should. I was testing on git version
1.7.9.5.
Put in a line in a file, call it:
first version
then cherry pick this into your branch. Then update on master and transform
that into:
second version
then, merge that branch back to master. Death in the
13 matches
Mail list logo
