> > + # Along with the merge bases, look at the first commit's > > + # parent (which may be before the merge base) and mark it > > + # as rewritten to ONTO > > + FIRST="$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)" > > + for p in $(git rev-list --parents -1 $FIRST | cut -d' ' -f2) > > + do > > + echo $ONTO > "$REWRITTEN/$p" > > + done > > AFAICT this is wrong. You have no guarantee whatsoever that the output of > > $ git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1 > > has any parents at all. Take for example a coolest-merge-ever, i.e. a > merge of an independent project. > > Instead, what you _actually_ are looking for are the boundary objects > of $UPSTREAM..$HEAD, Agreed. > which would be easy to get at. That would be great, but I'm not seeing it, obviously. Suggestions would be appreciated. > However, I have a strong feeling that just piling onto the current > code will not fix the underlying issues. Also agreed. So...not that it really matters, but did my patches go out to the git list or not? It looks like both Johannes and I got them from the cc entries. I tried to use format-patch and the files looked great, cc's including Michael, Stephan, and Sitaram. Then I ran send-email with the three files as arguments and it stripped all the cc's but Johannes and myself. Then I got all three delivered due to my cc entry, but I didn't see any entries arrive from the list even though the cc-delivered copies all had "To: git@xxxxxxxxxxxxxxx" in them (and that is what I had pasted into the send-email prompt). I guess I did something wrong but it's frustrating to not know what it was. - Stephen -- 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
