Re: [RFC/PATCH 2/1] fixup! Documentation: start to explain what git replace is for

From: Jakub Narebski <jnareb@gmail.com>
Date: Jan 14, 2011, 22:48 UTC
Message-ID: <201101142348.31647.jnareb@gmail.com>
In-Reply-To: <4D308B69.1050003@seznam.cz>

On Fri, 14 Jan 2011, Maaartin-1 wrote:

Show 11 quoted lines

> On 11-01-14 09:49, Jonathan Nieder wrote:
> > Some tweaks suggested by Maaartin:
> 
> [snip]
> 
>> [side note: please do not prune the cc list; I only stumbled on this
>> message in the online archive by luck]
> 
> What could I have done about it? I didn't received it by email and
> answered using post.gmane.org. There's no way to add CC there. If I'd
> wrote an email instead, it wouldn't be placed in the thread.

In a good newsreader, like e.g. Gnus from GNU Emacs, you have option to do 'reply all via email', which includes also git@vger.kernel.org, i.e. mailing list from which gmane newsgroup is created. That's what I do nowadays (usually).

Show 15 quoted lines

> [snip]
> 
>>>> +<1> Find all parentless commits in the 'master' branch;
>>>> +for 'master' read the branch holding v2.5 history.
>>>
>>> Aren't you later calling it "FIRST" and assuming there's only one?
>> 
>> Hmm.  I want to say that there _could_ be multiple parentless commits
>> in the v2.5 history and we are treating one of them as its root (just
>> like git master has multiple parentless ancestors but e83c5163 is
>> conventionally considered its beginning).  Not sure how to write that
>> clearly.
> 
> Maybe just something like "Let's assume there's only one and let's call
> it FIRST". For the example, this is enough.

That might be good enough, as I don't think that at beginning (where you
are creating current and archive repository) one would have multiple roots
from joining separate projects.

Show 6 quoted lines

>>> Isn't the combination of "-i" (=in-place edit) with redirection wrong?
>> 
>> Good catch (the "-i" is a typo).
> 
> I'd go the other way round and use "-i" so I'd need only one file. Using
> a shell variable instead would be even better, s. below.

No, using shell variable for storing commit object is *not* a good idea.
Either save it to temporary file, where you can edit it using editor of
your choice, or use pipeline.

Show 8 quoted lines

> [snip]
> 
> I tried to use the vars instead of files below, but never tested it. I
> used "first_commit" instead of both "tmp" and "new", which is not really
> nice.
> 
>> +$ git rev-list master --parents | grep -v ' '
>> +$ first=$(git rev-list master --parents | grep -v ' ') <1>

Or using always the oldest commit:

   +$ first=$(git rev-list master --date-order --parents | grep -v ' ' | tail -1) <1>

>> +$ git rev-parse v2.4                                   <2>

Let's save it to a variable too

   +$ join=$(git rev-parse v2.4)                           <2>

>> +$ git cat-file commit $first >tmp                      <3>

We can use COMMIT, or even FIRST as a file name here.

> $ first_commit = $(git cat-file commit FIRST)            <3>

No.  Just... no.

Show 9 quoted lines

> > +$ sed "/^tree / a \\
> > +parent $(git rev-parse v2.4)" <tmp >new                <4>
> 
> $ first_commit = $($ echo $first_commit |
> sed  "/^tree / a \\
> parent $(git rev-parse v2.4)")                      <4>
> 
> Unfortunately, the line got too long. For sed unaware people like me it
> may not be obvious that a line break is required.

No, it is not required, I think.

Show 10 quoted lines

> I'd use perl, anyway. 
> 
> $ first_commit = $($ echo $first_commit |
> perl -p
> "s/^tree .*/$&\nparent $(git rev-parse v2.4)/")      <4>
> 
> > +$ new_commit=$(git hash-object -t commit -w new)       <5>
> 
> $ new_commit=$(echo $first_commit |
> git hash-object -t commit -w --stdin)       <5>

If you don't use temporary file, which you can edit, you can use pipeline instead:

  $ new_commit=$(git cat-file commit $first_commit |
                 sed -e "/^tree / a\\parent $(git rev-parse v2.4)" |
                 git hash-object -t commit -w --stdin

  $ git replace $first_commit $new_commit

-- 
Jakub Narebski
Poland