Git: change content of previous commit and push [on hold]
up vote
0
down vote
favorite
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?
command-line git repository
put on hold as unclear what you're asking by RalfFriedl, G-Man, jimmij, Archemar, dhag 7 hours ago
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 2 more comments
up vote
0
down vote
favorite
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?
command-line git repository
put on hold as unclear what you're asking by RalfFriedl, G-Man, jimmij, Archemar, dhag 7 hours ago
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Why not commit your changes as new commits?
– Stephen Kitt
2 days ago
@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
2 days ago
I’m sorry, I don’t understand what you mean.
– Stephen Kitt
2 days ago
@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
2 days ago
1
BTW, ingit
,push
refers to pushing your commits to another repo. The command you are referring to iscommit
.
– Adrian
yesterday
|
show 2 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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?
command-line git repository
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?
command-line git repository
command-line git repository
asked 2 days ago
Tuyen Pham
547113
547113
put on hold as unclear what you're asking by RalfFriedl, G-Man, jimmij, Archemar, dhag 7 hours ago
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as unclear what you're asking by RalfFriedl, G-Man, jimmij, Archemar, dhag 7 hours ago
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Why not commit your changes as new commits?
– Stephen Kitt
2 days ago
@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
2 days ago
I’m sorry, I don’t understand what you mean.
– Stephen Kitt
2 days ago
@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
2 days ago
1
BTW, ingit
,push
refers to pushing your commits to another repo. The command you are referring to iscommit
.
– Adrian
yesterday
|
show 2 more comments
Why not commit your changes as new commits?
– Stephen Kitt
2 days ago
@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
2 days ago
I’m sorry, I don’t understand what you mean.
– Stephen Kitt
2 days ago
@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
2 days ago
1
BTW, ingit
,push
refers to pushing your commits to another repo. The command you are referring to iscommit
.
– Adrian
yesterday
Why not commit your changes as new commits?
– Stephen Kitt
2 days ago
Why not commit your changes as new commits?
– Stephen Kitt
2 days ago
@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
2 days ago
@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
2 days ago
I’m sorry, I don’t understand what you mean.
– Stephen Kitt
2 days ago
I’m sorry, I don’t understand what you mean.
– Stephen Kitt
2 days ago
@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
2 days ago
@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
2 days ago
1
1
BTW, in
git
, push
refers to pushing your commits to another repo. The command you are referring to is commit
.– Adrian
yesterday
BTW, in
git
, push
refers to pushing your commits to another repo. The command you are referring to is commit
.– Adrian
yesterday
|
show 2 more comments
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
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.
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 moveHEAD
to this new commit, I no longer be able to switch back tomaster
. Why is that?
– Tuyen Pham
yesterday
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 moveHEAD
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
yesterday
I check out prev commit, do changes, add and commit, git create new commit ahead of theprev commit
and movedHEAD
to it, then I try to checkoutmaster
,master
no longer there.
– Tuyen Pham
yesterday
@TuyenPham, when you checkout a prev commit, were you are still onmaster
? 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
yesterday
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 userebase
. See this answer for more information.
– Adrian
yesterday
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
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.
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 moveHEAD
to this new commit, I no longer be able to switch back tomaster
. Why is that?
– Tuyen Pham
yesterday
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 moveHEAD
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
yesterday
I check out prev commit, do changes, add and commit, git create new commit ahead of theprev commit
and movedHEAD
to it, then I try to checkoutmaster
,master
no longer there.
– Tuyen Pham
yesterday
@TuyenPham, when you checkout a prev commit, were you are still onmaster
? 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
yesterday
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 userebase
. See this answer for more information.
– Adrian
yesterday
add a comment |
up vote
1
down vote
accepted
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.
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 moveHEAD
to this new commit, I no longer be able to switch back tomaster
. Why is that?
– Tuyen Pham
yesterday
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 moveHEAD
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
yesterday
I check out prev commit, do changes, add and commit, git create new commit ahead of theprev commit
and movedHEAD
to it, then I try to checkoutmaster
,master
no longer there.
– Tuyen Pham
yesterday
@TuyenPham, when you checkout a prev commit, were you are still onmaster
? 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
yesterday
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 userebase
. See this answer for more information.
– Adrian
yesterday
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
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.
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.
edited 2 days ago
answered 2 days ago
Adrian
14719
14719
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 moveHEAD
to this new commit, I no longer be able to switch back tomaster
. Why is that?
– Tuyen Pham
yesterday
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 moveHEAD
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
yesterday
I check out prev commit, do changes, add and commit, git create new commit ahead of theprev commit
and movedHEAD
to it, then I try to checkoutmaster
,master
no longer there.
– Tuyen Pham
yesterday
@TuyenPham, when you checkout a prev commit, were you are still onmaster
? 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
yesterday
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 userebase
. See this answer for more information.
– Adrian
yesterday
add a comment |
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 moveHEAD
to this new commit, I no longer be able to switch back tomaster
. Why is that?
– Tuyen Pham
yesterday
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 moveHEAD
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
yesterday
I check out prev commit, do changes, add and commit, git create new commit ahead of theprev commit
and movedHEAD
to it, then I try to checkoutmaster
,master
no longer there.
– Tuyen Pham
yesterday
@TuyenPham, when you checkout a prev commit, were you are still onmaster
? 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
yesterday
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 userebase
. See this answer for more information.
– Adrian
yesterday
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
yesterday
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
yesterday
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
yesterday
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
yesterday
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
yesterday
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
yesterday
@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
yesterday
@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
yesterday
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
yesterday
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
yesterday
add a comment |
Why not commit your changes as new commits?
– Stephen Kitt
2 days ago
@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
2 days ago
I’m sorry, I don’t understand what you mean.
– Stephen Kitt
2 days ago
@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
2 days ago
1
BTW, in
git
,push
refers to pushing your commits to another repo. The command you are referring to iscommit
.– Adrian
yesterday