From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Christian Couder <chriscool@tuxfamily.org>, git@vger.kernel.org
Subject: Re: [PATCH 2/3] commit: add function to unparse a commit and its parents
Date: Mon, 18 May 2009 23:35:45 -0700 (PDT) [thread overview]
Message-ID: <m3r5ylk347.fsf@localhost.localdomain> (raw)
In-Reply-To: <7vws8d8y8i.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
> > By the way, when you say that you suspect an attempt to replace an object
> > that is directly listed on the command line would not work very well with
> > the current replace series, is it related to the unparsing commit problem?
>
> What I fear is something like this.
>
> git push $there 04a8c^2:master
>
> It would need to parse 04a8c to find its second parent and then start
> discussing what object to send with the other end. "04a8c^2" is a direct
> user input and should mean the same commit as git show "04a8c^2" would
> give the user, so it obviously needs to obey the replace rules (making
> 04a8c parsed), but the object transfer should not look at replace at all
> (that's the whole point of not using the "graft hack" that cannot be
> sanely transferred to the other end).
First, I have always thought that you cannot push arbitrary SHA-1
(arbitrary commits) in git; you can only push via refs. Isn't it true?
Second, the "refs/replace" mechanism has the advantage over grafts
that it is sanely transferrable. Whether "04a8c^2"^{replaced} exists
on remote side depends on if other side has the same replacement, or
if you push replacements in the same push.
Solution here could be to bail out and ask user to confirm whether
other side has the same replacements... or something like that.
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2009-05-19 6:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090517153307.6403.73576.>
2009-05-17 15:36 ` [PATCH 1/3] bisect: rework some rev related functions to make them more reusable Christian Couder
2009-05-17 15:36 ` [PATCH 2/3] commit: add function to unparse a commit and its parents Christian Couder
2009-05-18 6:27 ` Junio C Hamano
2009-05-19 4:16 ` Christian Couder
2009-05-19 5:20 ` Junio C Hamano
2009-05-19 6:35 ` Jakub Narebski [this message]
2009-05-19 7:02 ` Miles Bader
2009-05-19 7:14 ` Junio C Hamano
2009-05-19 7:48 ` Jakub Narebski
2009-05-25 9:17 ` Johannes Sixt
2009-05-25 9:46 ` Johannes Schindelin
2009-05-27 5:12 ` Christian Couder
2009-05-17 15:36 ` [PATCH 3/3] bisect: check ancestors without forking a "git rev-list" process Christian Couder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3r5ylk347.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).