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?










share|improve this 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, in git, push refers to pushing your commits to another repo. The command you are referring to is commit.
    – Adrian
    yesterday

















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?










share|improve this 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, in git, push refers to pushing your commits to another repo. The command you are referring to is commit.
    – Adrian
    yesterday















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?










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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, in git, push refers to pushing your commits to another repo. The command you are referring to is commit.
    – Adrian
    yesterday




















  • 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 is commit.
    – 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












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.






share|improve this answer























  • 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










  • 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










  • 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


















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.






share|improve this answer























  • 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










  • 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










  • 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















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.






share|improve this answer























  • 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










  • 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










  • 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













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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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 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










  • 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










  • 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


















  • 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










  • 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










  • 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
















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



Popular posts from this blog

Accessing regular linux commands in Huawei's Dopra Linux

Can't connect RFCOMM socket: Host is down

Kernel panic - not syncing: Fatal Exception in Interrupt