On Fri, 2014-08-01 at 09:56 -0700, Mike Stump wrote:
Since everything I do goes up and down into repositories and I don’t want my
friends and family to scorn me, rebase isn’t the command I want to use.
You completely mis-understand what published means. Published history
is history from which
On Thu, 2014-08-21 at 17:36 +, Keller, Jacob E wrote:
On Fri, 2014-08-01 at 09:56 -0700, Mike Stump wrote:
Since everything I do goes up and down into repositories and I don’t want
my friends and family to scorn me, rebase isn’t the command I want to use.
You completely mis-understand
[ sorry for the dup ]
Begin forwarded message:
On Aug 6, 2014, at 12:44 PM, Nico Williams n...@cryptonector.com 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.
On Aug 6, 2014, at 10:11 PM, Nico Williams n...@cryptonector.com 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
On Fri, Aug 08, 2014 at 10:34:43AM -0700, Mike Stump wrote:
On Aug 6, 2014, at 10:11 PM, Nico Williams n...@cryptonector.com 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
Nico Williams n...@cryptonector.com wrote:
On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote:
On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams n...@cryptonector.com wrote:
My proposal was to put this sort of ancillary history info in a
branch object (and that branches should
On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote:
I have been fiddling around in this area.
What I want to be able to do is develop fixes for open source code
that I run, and get those fixes upstream. This means I need a rebasing
workflow, to keep the patches up-to-date and to deal
Nico Williams n...@cryptonector.com wrote:
On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote:
But [a rebasing workflow] is inconvenient for deploying the patched
version to production (which is the point of developing the fixes) - I
want a fast-forwarding branch for that.
I'm
On Thu, Aug 07, 2014 at 05:42:34PM +0100, Tony Finch wrote:
Nico Williams n...@cryptonector.com wrote:
On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote:
But [a rebasing workflow] is inconvenient for deploying the patched
version to production (which is the point of developing
Nico Williams n...@cryptonector.com wrote:
On Thu, Aug 07, 2014 at 05:42:34PM +0100, Tony Finch wrote:
The problem is that the production branch gets copied around: pushed to
the repo server, pulled by other team members, etc. Forced pushes
are accident-prone, as is resetting a rebased
On Thu, Aug 7, 2014 at 12:47 PM, Tony Finch d...@dotat.at wrote:
Nico Williams n...@cryptonector.com wrote:
Either way I retain the old HEAD with some name.
Hmm, yes, I can see that would work. However my previous workflow was
rather branch-heavy and I found the accumulation of names
On Thu, Aug 7, 2014 at 6:38 AM, Tony Finch d...@dotat.at wrote:
So I have a small tool which maintains a publication branch which tracks
the head of a rebasing branch. It's reasonably satisfactory so far...
https://git.csx.cam.ac.uk/x/ucs/git/git-repub.git
... though the structure of the
On Wed, Aug 06, 2014 at 05:38:43PM -0700, Mike Stump wrote:
Oh, wait, maybe I have misunderstood the prohibition. I have:
upstream —— fsf
|
\
|
v
Me — master — coworker.
This looks a lot like what I meant about project repos.
Philip Oakley wrote:
From: Mike Stump mikest...@comcast.net
Sent: Friday, August 01, 2014 11:24 PM
On Aug 1, 2014, at 12:01 PM, Jakub Narębski jna...@gmail.com wrote:
It can work in Subversion because Subversion stores information about
what was merged in (and this includes cherry-picks, or
W dniu 2014-08-01 22:55, Nico Williams pisze:
On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Jonathan Nieder wrote:
Do you mean that git merge should be aware of what changes you have
already cherry-picked?
It isn't, and that's deliberate
That said, when today's
On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski jna...@gmail.com wrote:
W dniu 2014-08-01 22:55, Nico Williams pisze:
It would help if cherry-pick history where recorded somewhere (beyond
the reflog)...
Cherry-picks should record two parents, like merges.
(Of course, it does no good to know
On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams n...@cryptonector.com wrote:
On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski jna...@gmail.com wrote:
W dniu 2014-08-01 22:55, Nico Williams pisze:
It would help if cherry-pick history where recorded somewhere (beyond
the reflog)...
Cherry-picks
On Aug 6, 2014, at 8:43 AM, Jakub Narębski jna...@gmail.com 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
On Aug 1, 2014, at 4:40 PM, Nico Williams n...@cryptonector.com 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
On Wed, Aug 06, 2014 at 12:11:16PM -0700, Mike Stump wrote:
On Aug 1, 2014, at 4:40 PM, Nico Williams n...@cryptonector.com 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
On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote:
On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams n...@cryptonector.com wrote:
My proposal was to put this sort of ancillary history info in a
branch object (and that branches should be objects). This would
have a number of
On Wed, Aug 06, 2014 at 02:44:59PM -0500, Nico Williams wrote:
That means that you have/maintain an intermediate upstream, yes?
This is a bit trickier since once in a while that intermediate upstream
and everyone downstream of it has to catch up with the real upstream.
Here you have two
Jakub Narębski jna...@gmail.com writes:
There was (long time ago) a long thread about idea of adding some
kind of 'weak' references (links), 'weakparent' that can be
automatically used by Git but do not pollute the commit message,
and do not affect reachability calculations. Ultimately it
Junio C Hamano gits...@pobox.com writes:
Jakub Narębski jna...@gmail.com writes:
There was (long time ago) a long thread about idea of adding some
kind of 'weak' references (links), 'weakparent' that can be
automatically used by Git but do not pollute the commit message,
and do not affect
From: Mike Stump mikest...@comcast.net
Sent: Friday, August 01, 2014 11:10 PM
On Aug 1, 2014, at 11:57 AM, Philip Oakley philipoak...@iee.org
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
From: Mike Stump mikest...@comcast.net
Sent: Friday, August 01, 2014 11:24 PM
On Aug 1, 2014, at 12:01 PM, Jakub Narębski jna...@gmail.com 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
From: Mike Stump mikest...@comcast.net
Sent: Friday, August 01, 2014 11:10 PM
(part 2)
On Aug 1, 2014, at 11:57 AM, Philip Oakley philipoak...@iee.org
wrote:
For some central control use styles, the ideas behind _distributed_
version control are anathema and (Git) just grinds away at the
W dniu 2014-08-01 04:43, brian m. carlson pisze:
On Thu, Jul 31, 2014 at 05:58:17PM -0700, Mike Stump wrote:
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
On Jul 31, 2014, at 7:43 PM, brian m. carlson sand...@crustytoothpaste.net
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.
On Aug 1, 2014, at 9:27 AM, Jakub Narębski jna...@gmail.com 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
From: Mike Stump mikest...@comcast.net
On Aug 1, 2014, at 9:27 AM, Jakub Narębski jna...@gmail.com 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
[sorry for duplicate sent as private mail; I forgot to turn off HTML
when sending to the git mailing list]
On Fri, Aug 1, 2014 at 7:48 PM, Mike Stump mikest...@comcast.net wrote:
[...]
I was curious if svn handles this better the same or worse, and it did it
just fine. I know that a while
On Thursday, July 31, 2014, Mike Stump mikest...@comcast.net wrote:
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
Hi Mike,
Mike Stump wrote:
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
On 08/01/2014 10:48 AM, Mike Stump wrote:
There is also git-imerge, third party tool that is intended to help
merging changes (and make it possible to do it in incremental way).
Then remove git merge and replace it with git-imerge. :-) Anyway, I read
that, and I can see some beauty of that
Jonathan Nieder wrote:
Do you mean that git merge should be aware of what changes you have
already cherry-picked?
It isn't, and that's deliberate
That said, when today's git merge fails to resolve conflicts, it's
easily possible that we could do better at resolving the merge by
walking
On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Jonathan Nieder wrote:
Do you mean that git merge should be aware of what changes you have
already cherry-picked?
It isn't, and that's deliberate
That said, when today's git merge fails to resolve conflicts, it's
Nico Williams n...@cryptonector.com writes:
Cherry-picks should record two parents, like merges.
No.
It is OK to record where it came from, and we let you do so with the
-x option.
But the where it came from commit is very different from being
parent, which implies all the history behind it.
On Fri, Aug 1, 2014 at 4:44 PM, Junio C Hamano gits...@pobox.com wrote:
Nico Williams n...@cryptonector.com writes:
Cherry-picks should record two parents, like merges.
No.
It is OK to record where it came from, and we let you do so with the
-x option.
But the where it came from commit
Nico Williams n...@cryptonector.com writes:
branch, and what commit it was on that other branch, and right now the
only place where that information is available is in the reflog.
... or the line in -x.
We do not add random unstructured cruft in the commit object
header. Check the list
On Aug 1, 2014, at 12:22 PM, Nico Williams n...@cryptonector.com 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
On Aug 1, 2014, at 11:57 AM, Philip Oakley philipoak...@iee.org 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
On Fri, Aug 1, 2014 at 5:13 PM, Mike Stump mikest...@comcast.net wrote:
On Aug 1, 2014, at 12:22 PM, Nico Williams n...@cryptonector.com wrote:
If you always rebase
I can’t use rebase unless you make rebase work with multiple users and
pushing pulling.
That works now, and I do it all the
On Aug 1, 2014, at 12:01 PM, Jakub Narębski jna...@gmail.com 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,
On Aug 1, 2014, at 1:02 PM, Jonathan Nieder jrnie...@gmail.com 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
Mike Stump wrote:
On Aug 1, 2014, at 1:02 PM, Jonathan Nieder jrnie...@gmail.com wrote:
It isn't, and that's deliberate
Deliberate bugs are still bugs.
Yes, you and I disagree about what the behavior should be.
I actively prefer the current behavior over the one you proposed,
unless I'm
On Aug 1, 2014, at 1:12 PM, Sam Vilain s...@vilain.net 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
On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump mikest...@comcast.net wrote:
On Aug 1, 2014, at 1:12 PM, Sam Vilain s...@vilain.net 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
On Aug 1, 2014, at 1:50 PM, Jonathan Nieder jrnie...@gmail.com 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
On Fri, 2014-08-01 at 18:40 -0500, Nico Williams wrote:
On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump mikest...@comcast.net wrote:
On Aug 1, 2014, at 1:12 PM, Sam Vilain s...@vilain.net wrote:
Git merge has a notion of discrete merge strategies”.
There's no particular reason that you
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
On Thu, Jul 31, 2014 at 05:58:17PM -0700, Mike Stump wrote:
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:
52 matches
Mail list logo
