Junio C Hamano venit, vidit, dixit 21.12.2012 17:58:
> Michael J Gruber writes:
>
>> While replace refs are much more general than grafts, it seems the two
>> main uses are:
>>
>> - grafts (change the recorded parents for a commit)
>> - svn cleanup (convert tagging commits into tag objects)
>>
>>
Michael J Gruber writes:
> While replace refs are much more general than grafts, it seems the two
> main uses are:
>
> - grafts (change the recorded parents for a commit)
> - svn cleanup (convert tagging commits into tag objects)
>
> The latter one being quite a special case already.
>
> The scri
While replace refs are much more general than grafts, it seems the two
main uses are:
- grafts (change the recorded parents for a commit)
- svn cleanup (convert tagging commits into tag objects)
The latter one being quite a special case already.
The script below has helped me move from grafts to
Thomas Rast writes:
> I still wouldn't recommend this approach in git-replace(1) for several
> reasons:
>
> * It does not generalize in any direction. For each field you may want
> to change, you have to know a _specific_ way of getting just the
> commit you want.
>
> * More to the point of
Junio C Hamano writes:
> I do not understand why you even want to go in the harder route in
> the first place, only to complicate things?
>
> All you want to do is to craft a commit object that records a
> specific tree shape, has a set of parents you want, and has the log
> information you want.
On Wed, Dec 19, 2012 at 08:13:21AM +0100, Johannes Sixt wrote:
> Am 12/18/2012 17:24, schrieb Jeff King:
> > I am not really interested in pushing this forward myself, but I worked
> > up this toy that somebody might find interesting (you can "git replace
> > HEAD~20" to get dumped in an editor).
On Tue, 18 Dec 2012 08:09:35 -0800
Junio C Hamano wrote:
> Yann Dirson writes:
>
> > On Mon, 17 Dec 2012 13:14:56 -0800
> > Junio C Hamano wrote:
> >
> >> Andreas Schwab writes:
> >>
> >> > Christian Couder writes:
> >> >
> >> >> Yeah, at one point I wanted to have a command that created to
Am 12/18/2012 17:24, schrieb Jeff King:
> I am not really interested in pushing this forward myself, but I worked
> up this toy that somebody might find interesting (you can "git replace
> HEAD~20" to get dumped in an editor). It should probably handle trees,
> and it would probably make sense to d
On Tue, Dec 18, 2012 at 02:41:57PM +0100, Yann Dirson wrote:
> > I wouldn't even want a script -- we'd end up inventing a complicated
> > command-line editor for what can simply be done by judicious use of an
> > actual text editor. How about something like the following?
>
> Well, while it does
Yann Dirson writes:
> On Mon, 17 Dec 2012 13:14:56 -0800
> Junio C Hamano wrote:
>
>> Andreas Schwab writes:
>>
>> > Christian Couder writes:
>> >
>> >> Yeah, at one point I wanted to have a command that created to craft a
>> >> new commit based on an existing one.
>> >
>> > This isn't hard t
Yann Dirson writes:
>> +EXAMPLE
>> +---
>> +
>> +Replacements (and before them, grafts) are often used to replace the
>> +parent list of a commit. Since commits are stored in a human-readable
>> +format, you can in fact change any property using the following
>> +recipe:
>> +
>> +---
On Tue, 18 Dec 2012 13:49:44 +0100
Thomas Rast wrote:
> Johannes Sixt writes:
>
> > Am 12/18/2012 12:00, schrieb Yann Dirson:
> >> On Mon, 17 Dec 2012 13:14:56 -0800
> >> Junio C Hamano wrote:
> >>
> >>> Andreas Schwab writes:
> >>>
> Christian Couder writes:
>
> > Yeah, at on
Johannes Sixt writes:
> Am 12/18/2012 12:00, schrieb Yann Dirson:
>> On Mon, 17 Dec 2012 13:14:56 -0800
>> Junio C Hamano wrote:
>>
>>> Andreas Schwab writes:
>>>
Christian Couder writes:
> Yeah, at one point I wanted to have a command that created to craft a
> new commit ba
Am 12/18/2012 12:00, schrieb Yann Dirson:
> On Mon, 17 Dec 2012 13:14:56 -0800
> Junio C Hamano wrote:
>
>> Andreas Schwab writes:
>>
>>> Christian Couder writes:
>>>
Yeah, at one point I wanted to have a command that created to craft a
new commit based on an existing one.
>>>
>>> Thi
On Mon, 17 Dec 2012 13:14:56 -0800
Junio C Hamano wrote:
> Andreas Schwab writes:
>
> > Christian Couder writes:
> >
> >> Yeah, at one point I wanted to have a command that created to craft a
> >> new commit based on an existing one.
> >
> > This isn't hard to do, you only have to resort to pl
Andreas Schwab writes:
> Christian Couder writes:
>
>> Yeah, at one point I wanted to have a command that created to craft a
>> new commit based on an existing one.
>
> This isn't hard to do, you only have to resort to plumbing:
>
> $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62
Christian Couder writes:
> Yeah, at one point I wanted to have a command that created to craft a
> new commit based on an existing one.
This isn't hard to do, you only have to resort to plumbing:
$ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed
s/bfae342c973b0be3c9e99d3d86e
On Mon, 17 Dec 2012 14:43:59 +0100
Christian Couder wrote:
> Hi Yann,
>
> On Mon, Dec 17, 2012 at 11:40 AM, Yann Dirson wrote:
> > On Mon, 17 Dec 2012 09:43:53 +0100
> > Thomas Rast wrote:
> >
> >> Junio C Hamano writes:
> >>
> >>
> >> I suppose there's the additional issue that grafts are mu
Hi Yann,
On Mon, Dec 17, 2012 at 11:40 AM, Yann Dirson wrote:
> On Mon, 17 Dec 2012 09:43:53 +0100
> Thomas Rast wrote:
>
>> Junio C Hamano writes:
>>
>>
>> I suppose there's the additional issue that grafts are much easier to
>> use than replacements if you really only want to replace some par
On Mon, 17 Dec 2012 09:43:53 +0100
Thomas Rast wrote:
> Junio C Hamano writes:
>
> > Yann Dirson writes:
> >
> >> In this respect, they seem to be
> >> lacking a few features, when compared to "replace" refs, but they have
> >> different
> >> uses, ...
> >
> > Not reallyl; grafts were o
On Mon, 17 Dec 2012 00:56:06 -0800
Junio C Hamano wrote:
> Yann Dirson writes:
>
> > And we may still want the bug fixed, or would we just list it as a known
> > bug ?
> > At least it does not seem to occur with "replace" refs:
>
> The "replace" was designed to "fix" known limitation of graft
Yann Dirson writes:
> And we may still want the bug fixed, or would we just list it as a known bug ?
> At least it does not seem to occur with "replace" refs:
The "replace" was designed to "fix" known limitation of grafts,
which is _inherent_ to it; the graft information was designed _not_
to be
Junio C Hamano writes:
> Yann Dirson writes:
>
>> In this respect, they seem to be
>> lacking a few features, when compared to "replace" refs, but they have
>> different
>> uses, ...
>
> Not reallyl; grafts were old hack whose use is still supported with
> its original limitations; replac
On Wed, 12 Dec 2012 11:57:47 -0800
Junio C Hamano wrote:
> Yann Dirson writes:
>
> > In this respect, they seem to be
> > lacking a few features, when compared to "replace" refs, but they have
> > different
> > uses, ...
>
> Not reallyl; grafts were old hack whose use is still supported
Yann Dirson writes:
> In this respect, they seem to be
> lacking a few features, when compared to "replace" refs, but they have
> different
> uses, ...
Not reallyl; grafts were old hack whose use is still supported with
its original limitations; replace is meant to replace all uses of
gra
On Wed, 12 Dec 2012 09:44:32 +0100 Yann Dirson wrote:
> In fact, I even looked for a way to specify an alternate (or supplementary)
> grafts file for this drafting work, so only well-controlled git invocations
> would see them, whereas the others would just ignore them, and could not find
> any -
On Tue, 11 Dec 2012 10:15:23 -0800
Junio C Hamano wrote:
> Yann Dirson writes:
>
> > There seems to be some bad interactions between git-push and grafts.
> > The problem seems to occur when a commit that exists in the remote
> > repo is subject to a graft in the local repo, and we try to push o
Yann Dirson writes:
> There seems to be some bad interactions between git-push and grafts.
> The problem seems to occur when a commit that exists in the remote
> repo is subject to a graft in the local repo, and we try to push one
> of the fake parents.
History tweaking by grafts is only visible
There seems to be some bad interactions between git-push and grafts.
The problem seems to occur when a commit that exists in the remote
repo is subject to a graft in the local repo, and we try to push one
of the fake parents.
The problem was first seen on 1.7.12.3 in a private repo, and I could
re
29 matches
Mail list logo
