solidity
solidity copied to clipboard
ethereum
Docs — Minor grammar fixes in `abi-spec.rst`
Category:
- [x] Documentation -> Grammar
Description:
Minor grammar fixes in abi-spec.rst.
Note: Please excuse the ambiguous branch name, I edited the file directly on GitHub; hence, it named and created the branch automatically.
@chriseth Sorry, how can do I that? Is it via squash merging into the develop branch of my fork?
No, squash-merging is a different thing. You have to rebase your own fork interactively (git rebase -i origin/develop) and then use "squash" on the second commit. After that you have to force-push to your branch (git push --force).
Got it, I will do it now.
By the way, in my case specifically does it matter if I just delete that extraneous commit altogether instead of squashing it?
You mean the commit that deletes the :? It is not "extraneous" as we want that change, right? But it should be part of the first commit.
I believe there is some kind of misunderstanding here.. but I am fairly certain what you want is what chris was describing. It is a bit better explained here (squash and fixup are basically the same): https://www.mikulskibartosz.name/git-fixup-explained/
@Marenz To clear the misunderstanding let's simplify. Ok, so there are two commits:
Minor grammar fixes and Fixes :
The one not needed is Minor grammar fixes -- so, I was just enquiring if in my case (after the interactive rebase): it makes any difference to just delete Minor grammar fixes than to squash it into one.
But Minor grammar fixes contains 99% of your changes and Fixes : only a correction to those previous changes, why do you think it is not needed?
If you delete the first, the second is just the removal of the : which by then doesn't exist anymore as the addition of it was in the first..
I assumed the latter commit incorporates the changes from that commit -- I guess I will just squash it then. Thank you
Squashing does exactly that. A commit is only a state in the repository if it is still attached to its previous commit. Without that it is just a set of changes.
So while the state is what we want at the Fixes : commit, the change-set in it is only the removal of :.
That clarified it, thank you. My rebase is done locally -- I also did git push --force but got the following message: "everything up-to-date".
Side-note: Also, does the order precedence matter when squashing? For instance, Commit B before Commit A being squashed; would this yield the same result as Commit B after Commit A being squashed?
It does not look like the squashing actually worked - I still see two commits :-).
git rebase -i origin/develop should have opened an editor to specify how to rebase and in particular, which commits to squash. Are you sure you requested the second commit to be squashed in there?
Also wrt to your question: you always squash a subsequent commit into the commit before it, i.e. if you have commit A followed by commit B, you have to squash B into A, not the other way round.
Apart from this, I'd say we can merge this.
