On Thu, May 22, 2014 at 11:33:04PM +0200, Christian Couder wrote:
> The usage string for this option is:
>
> git replace [-f] --graft <commit> [<parent>...]
>
> First we create a new commit that is the same as <commit>
> except that its parents are [<parents>...]
>
> Then we create a replace ref that replace <commit> with
> the commit we just created.
>
> With this new option, it should be straightforward to
> convert grafts to replace refs, with something like:
>
> cat .git/info/grafts | while read line
> do git replace --graft $line; done
I think this script at the end should end up in the documentation or a
contrib script (probably the former, as it is short enough that somebody
might just cut-and-paste).
The graft file ignores comments and blank lines, so maybe "grep '^[^#]'"
would be in order.
And maybe it's just me, but I think spacing it like:
grep '^[^#]' .git/info/grafts |
while read line; do
git replace --graft $line
done
is more readable (I think some would even argue for putting the "do" on
a separate line).
> + /* make sure the commit is not corrupt */
> + if (parse_commit_buffer(commit, buf.buf, buf.len))
> + die(_("Could not parse commit: '%s'"), old_ref);
I guess the checks here are sufficient to make...
> + /* find existing parents */
> + parent_start = buf.buf;
> + parent_start += 46; /* "tree " + "hex sha1" + "\n" */
> + parent_end = parent_start;
> +
> + while (starts_with(parent_end, "parent "))
> + parent_end += 48; /* "parent " + "hex sha1" + "\n" */
...this number-based parsing safe, though it would miss removing a stray
parent line elsewhere in the commit. It still feels rather magical to
me, as we are depending on unspoken format guarantees defined inside
parse_commit_buffer. I'd prefer something like the line-based parser I
showed in the other thread, but I suppose it may just be a matter of
preference.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
