I realized that I had made the commit in the submodule and that wasn't going to work so I made the two identical commits (copy pasted from temporary text files). Should submodule commit 9fe303b064624df441a038f4853dd2954c506df7 be reverted as it's redundant and doesn't affect the upstream actual librersicv repo?

A submodule is a full git repo, so you can add the writable version of the remote and push the commit:
cd <path>/soc/libreriscv
git remote add origin2 ssh://gitolite3@git.libre-riscv.org:922/libreriscv.git
git fetch origin2
git checkout 9fe303b064624df441a038f4853dd2954c506df7
git tag bug-440
git push --tags origin2
cd ..
git submodule update

(In reply to Cole Poirier from comment #1)
> I realized that I had made the commit in the submodule and that wasn't going
> to work so I made the two identical commits (copy pasted from temporary text
> files). Should submodule commit 9fe303b064624df441a038f4853dd2954c506df7 be
> reverted as it's redundant and doesn't affect the upstream actual librersicv
> repo?

it doesn't matter if you decide to revert or not even include the commit in master, what does matter is that the exact same commit exists in libreriscv.git so people using soc.git can successfully use each commit without running into problems due to not being able to checkout the submodule.

(In reply to Jacob Lifshay from comment #2)
> A submodule is a full git repo, so you can add the writable version of the
> remote and push the commit:

funny.  i suggested another way, involving git format-patch and git am apply which effectively achieves the same thing.

which ironically i just had to do last night as i did the exact same thing as cole.

anyway. given that the same text has been added and given that the submodule has moved on i'm closing this one.

(In reply to Luke Kenneth Casson Leighton from comment #4)
> (In reply to Jacob Lifshay from comment #2)
> > A submodule is a full git repo, so you can add the writable version of the
> > remote and push the commit:
> 
> funny.  i suggested another way, involving git format-patch and git am apply
> which effectively achieves the same thing.

It may end up with the same content, but it doesn't give the same commit hash, unfortunately. The git submodule mechanism depends on having exactly the same commit hash.
 
> which ironically i just had to do last night as i did the exact same thing
> as cole.
> 
> anyway. given that the same text has been added and given that the submodule
> has moved on i'm closing this one.

I really think cole should push that commit, since people exploring the git history or git bisecting will have trouble if it isn't actually there.

Also, we should have it there for the sake of transparency.

reopening.

(In reply to Jacob Lifshay from comment #5)
> (In reply to Luke Kenneth Casson Leighton from comment #4)
> > (In reply to Jacob Lifshay from comment #2)
> > > A submodule is a full git repo, so you can add the writable version of the
> > > remote and push the commit:
> > 
> > funny.  i suggested another way, involving git format-patch and git am apply
> > which effectively achieves the same thing.
> 
> It may end up with the same content, but it doesn't give the same commit
> hash, unfortunately. The git submodule mechanism depends on having exactly
> the same commit hash.
>  
> > which ironically i just had to do last night as i did the exact same thing
> > as cole.
> > 
> > anyway. given that the same text has been added and given that the submodule
> > has moved on i'm closing this one.
> 
> I really think cole should push that commit, since people exploring the git
> history or git bisecting will have trouble if it isn't actually there.
> 
> Also, we should have it there for the sake of transparency.
> 
> reopening.

I would have committed it if I still had it. In my attempt to get the changes I had committed to the submodule into the actual repo I deleted soc and pulled it fresh from our git. Luke told me that instead of trying to resolve git confusions on my own I should contact the mailing list so I don't make these kinds of mistakes. I will endeavor to do this moving forwards. Closing.

(In reply to Cole Poirier from comment #6)
> I would have committed it if I still had it. In my attempt to get the
> changes I had committed to the submodule into the actual repo I deleted soc
> and pulled it fresh from our git. Luke told me that instead of trying to
> resolve git confusions on my own I should contact the mailing list so I
> don't make these kinds of mistakes. I will endeavor to do this moving
> forwards. Closing.

oh well, everyone makes mistakes.

(In reply to Jacob Lifshay from comment #7)

> oh well, everyone makes mistakes.

sorry i forgot to mention i'd spoken with cole a couple days ago and witnessed a hilarious head-desk-banging session when describing the lovely simple solution :)

i had suspected that git format-patch and git am apply (designed for offline emailable git synchronisation) were capable of preserving the git commit hashes, not having used it in a while, and ironically confirmed this works, only yesterday.

by the round-the-houses route of putting the commit into a formatpatch, when i did the pull on the submodule it went "oh you already have this i will just update the git log then, ho hum nothing to see here, moving on, yawn"

if however i had done straight "patch" with a diff then definitely there would be two conflicting commits with the exact same content and that would have been Bad (tm).

(In reply to Luke Kenneth Casson Leighton from comment #8)
> (In reply to Jacob Lifshay from comment #7)
> 
> > oh well, everyone makes mistakes.
> 
> sorry i forgot to mention i'd spoken with cole a couple days ago and
> witnessed a hilarious head-desk-banging session when describing the lovely
> simple solution :)
> 
> i had suspected that git format-patch and git am apply (designed for offline
> emailable git synchronisation) were capable of preserving the git commit
> hashes, not having used it in a while, and ironically confirmed this works,
> only yesterday.

Well, they don't actually preserve the git commit hash, since git format-patch and git am apply save the content, author and author timestamps. They do not contain the committer and committer timestamps.

See https://stackoverflow.com/a/26130094/2597900
There's probably a better reference on Git's website.

(In reply to Jacob Lifshay from comment #9)

> Well, they don't actually preserve the git commit hash, since git
> format-patch and git am apply save the content, author and author
> timestamps. They do not contain the committer and committer timestamps.

ah that's interesting and good to know.  thank you for investigating more thoroughly