0

I'm reviewing a repo and I'd like to make some comments, it would add more content like adding comments, make some changes ..etc.

How to change content of files of previous commit and do push, I'm aware that commit history would be changed and all affected files would be changed also, but would git compare the affected files with further commits (--> Master) and do change aggressively?

7
  • Why not commit your changes as new commits? Dec 10, 2018 at 14:11
  • @StephenKitt: When investigating a repo that from first commit back to current one, I need something aggressively forward changes (comments) as next commits.
    – Tuyen Pham
    Dec 10, 2018 at 14:54
  • I’m sorry, I don’t understand what you mean. Dec 10, 2018 at 15:08
  • @StephenKitt: e.g: through first commit, I make some comments, then push, go to next one, have some changes from author and I do some comments (this time only on the changes), push, and again..
    – Tuyen Pham
    Dec 10, 2018 at 15:16
  • 1
    BTW, in git, push refers to pushing your commits to another repo. The command you are referring to is commit.
    – Adrian
    Dec 11, 2018 at 19:26

1 Answer 1

1

What you are asking for is to rewrite history n to 0 commits back. This is generally a bad idea as it would make you repo out of sync from the remote and any other repo that is based on it. This would further complicate things so that others wouldn't be able to merge anymore and would require any other repo to delete their branch and pull down the newly modified one. In which case, you might as well just start a new branch and add the comments to that. In any case, this'll get a little messy.

To do this, you have your merges that you would be reviewing (as an example, we'll use commits A, B and C) and then go back to A, branch off that (we'll call that branch review, and the original pull-request):

...A --B --C    (pull-request)
    \
     A'         (review)

git checkout HEAD{3}
git checkout -b review

Then do your comment modifications and check them in.

git add . # or specify the specific files 
git commit -m "message" --author="original author"

Or if you want the same message/author and don't want to type it out, you can use the following, which I would either put into a script or an alias git command:

git add $(git diff-tree --no-commit-id --name-only -r <sha-of-A>)
git commit -m "$(git rev-list --format=%B <sha-of-a>)" --author="$(git rev-list --format=%an <sha-of-A>)"

Could also be done automatically by retrieving the appropriate sha from the appropriate parent, but I'm not exactly sure how to distinguish between the branch parent and the merge parent atm.

Next merge B into review

git merge <sha-of-B>

Then do your comment modifications and check them in. (see above).

Keep doing this till you're done and you have:

...A --B --C    (pull-request)
    \   \   \
     A'--B'--C' (review)

You can then merge back into your original branch if you wish or just give that review branch back to the person from which you are reviewing.

5
  • Thanks, in my case, I only review other codes and never do push on shared repo, I didn't make it clear on the first post. I try to make change in one of prev commit, add and give commit: git commit -m "test" but git detach from current commit and move ahead one separate commit for the new changes and also move HEAD to this new commit, I no longer be able to switch back to master. Why is that?
    – Tuyen Pham
    Dec 11, 2018 at 1:09
  • Sorry @TuyenPham, I'm having a little problem parsing your comment. What do you mean by "I try to make change in one of prev commit, add and give commit: git commit -m "test" but git detach from current commit and move ahead one separate commit for the new changes and also move HEAD to this new commit," I think you are saying that you checked out a version by its sha, made changes and then tried to commit but it wouldn't let you. And when you tried to checkout master, it wouldn't let you do that either. Is that correct?
    – Adrian
    Dec 11, 2018 at 4:46
  • I check out prev commit, do changes, add and commit, git create new commit ahead of the prev commit and moved HEAD to it, then I try to checkout master, master no longer there.
    – Tuyen Pham
    Dec 11, 2018 at 4:50
  • @TuyenPham, when you checkout a prev commit, were you are still on master? A commit node can only have one parent unless it is a merge point and can only one child unless it is a branch point. So, by committing a new commit, you unlink the original child node commit and replaced it with yours. The original commit is still there, it is just not reachable, and will be eventually erased in the next garbage collection cycle. If you want the original and your modification to both be children of the parent node, you have to branch.
    – Adrian
    Dec 11, 2018 at 5:28
  • You can't just modify what is already there, without rewriting all of the successive child nodes. If you want to do that, you can use rebase. See this answer for more information.
    – Adrian
    Dec 11, 2018 at 5:28

Not the answer you're looking for? Browse other questions tagged .