Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Nov 6, 2011, 04:31 UTC
- Message-ID
- <20111106043157.GM27272@elie.hsd1.il.comcast.net>
- In-Reply-To
- <1320535407-4933-2-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier wrote:
> This happens only when the corresponding commits are not exported in > the current fast-export run. This can happen either when the relevant > commit is already marked, or when the commit is explicitly marked > as UNINTERESTING with a negative ref by another argument.
The above "This" has no antecedent. I guess you mean that fast-export writes no output when passed a range of the form A..A.
> This breaks fast-export based remote helpers,
Makes sense.
Show 13 quoted lines
> as they use marks
> files to store which commits have already been seen. The call graph
> is something as follows:
>
> $ # push master to remote repo
> $ git fast-export --{im,ex}port-marks=marksfile master
> $ # make a commit on master and push it to remote
> $ git fast-export --{im,ex}port-marks=marksfile master
> $ # run `git branch foo` and push it to remote
> $ git fast-export --{im,ex}port-marks=marksfile foo
>
> When fast-export imports the marksfile and sees that all commits in
> foo are marked as UNINTERESTINGHmm, I didn't know about this behavior. Would it be possible to add a test for it, too?
> t/t9350-fast-export.sh | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-)
With or without the change suggested above, this new test seems to me like a good thing, even though in the longer term it might be nicer to teach fast-export to understand a syntax like
git fast-import ^master master:master
Put another way, the possibility of something nicer later shouldn't stop us from adding an incremental refinement that improves things today.
Thanks for working on this, Jonathan