On Fri, 14 Jan 2011, Maaartin-1 wrote:
> 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@xxxxxxxxxxxxxxx,
i.e. mailing list from which gmane newsgroup is created. That's what
I do nowadays (usually).
> [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.
>>> 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.
> [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.
> > +$ 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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html