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-unde
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 whi
On Fri, Aug 08, 2014 at 10:34:43AM -0700, Mike Stump wrote:
> 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
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 Thu, Aug 7, 2014 at 6:38 AM, Tony Finch 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 publication
On Thu, Aug 7, 2014 at 12:47 PM, Tony Finch wrote:
> Nico Williams 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 annoying. I have
> not yet had enough
Nico Williams 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 branch after a
On Thu, Aug 07, 2014 at 05:42:34PM +0100, Tony Finch wrote:
> Nico Williams 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
Nico Williams 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 not sure I fol
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
Nico Williams 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 wrote:
> > >
> > > My proposal was to put this sort of ancillary history info in a
> > > "branch object" (and that branches should be objects).
> >
> > Is it so
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 pro
Junio C Hamano writes:
> Jakub Narębski 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
Jakub Narębski 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 went
> nowhere
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 t
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 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 benefits, not the l
On Wed, Aug 06, 2014 at 12:11:16PM -0700, Mike Stump wrote:
> 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 other
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 Wed, Aug 6, 2014 at 6:26 PM, Nico Williams wrote:
> On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski 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 pa
On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski 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 abo
W dniu 2014-08-01 22:55, Nico Williams pisze:
On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder 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
Philip Oakley wrote:
From: "Mike Stump"
Sent: Friday, August 01, 2014 11:24 PM
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:
From: "Mike Stump"
Sent: Friday, August 01, 2014 11:10 PM
(part 2)
On Aug 1, 2014, at 11:57 AM, Philip Oakley
wrote:
For some central control use styles, the ideas behind _distributed_
version control are anathema and (Git) just grinds away at the
policies that are expected.
...
of the 'rela
From: "Mike Stump"
Sent: Friday, August 01, 2014 11:24 PM
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
From: "Mike Stump"
Sent: Friday, August 01, 2014 11:10 PM
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 t
On Fri, 2014-08-01 at 18:40 -0500, Nico Williams wrote:
> On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump wrote:
> > 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
> >>
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 Fri, Aug 1, 2014 at 6:06 PM, Mike Stump wrote:
> 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 doe
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
Mike Stump wrote:
> On Aug 1, 2014, at 1:02 PM, Jonathan Nieder 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 misunderstanding
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 Fri, Aug 1, 2014 at 5:13 PM, Mike Stump wrote:
> 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.
That works now, and I do it all the time. Have a single repo ("the
truth")
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
Nico Williams 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 archive.
--
To unsubscr
On Fri, Aug 1, 2014 at 4:44 PM, Junio C Hamano wrote:
> Nico Williams 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 be
Nico Williams 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". The whole poin
On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder 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
> easi
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
walkin
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
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,
On Thursday, July 31, 2014, 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:
>
> se
[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 wrote:
[...]
>
> I was curious if svn handles this better the same or worse, and it did it
> just fine. I know that a while ago, svn could not ha
From: "Mike Stump"
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 f
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
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 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
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
52 matches
Mail list logo
