Removing unwanted changes from git

[FuPeiJiang]

I can't use .gitignore, because I want everything to be saved to remote,
if "git update-index --assume-unchanged" removes files from remote, that's not what I need

I'm currently trying to make a vscode extension to generate branch from branch using diffs I specify.

[FuPeiJiang]

progress report: I can now generate file
from

using

to

remember: javascript arrray start at 0, so line 0 is line 1
(I'm talking about before my changes) line 0 was removed, line 8 was replaced, line 12 was replaced
but you see that it was ACTUALLY line 16 and line 22 that were replaced
that's because (highlighted in green) line [0-4], line [13-15], line [20-21] where added by me (compared to last commit) (using git diff my vscode extension can see this)

so before my changes, line 16 was at line 8, the reason line 8 is now at line 15 is because text.txt.json removed line 0

I DO NOT KNOW how the changes highlighting (green) works, is it built-in vscode ? can I easily get these instead of calling git diff myself ?
well, I'm already calling git diff and parsing the output so...

[mark-wiemer]

RE changes highlighting: I think it is built into VS Code, based off the fact that it's present even when there are no extensions enabled. VS Code is open source though! But I would say the best way is to call git diff yourself as you are now.

This is a really interesting project! It seems like you've made progress too, which is great.

Have you looked into update-index --assume-unchanged? It's great if you want to keep files on your local machine different from files in the remote repo. It doesn't affect the remote repo at all (I remember you asked about this the first time I mentioned it).

[FuPeiJiang]

It's great if you want to keep files on your local machine different from files in the remote repo.

but then, my files wouldn't be saved to remote (backup), this also means these files are not accessible on another computer.

for maximum flexibility, I also want a solution that can allow me to have inline differences, not only file differences

I have just found something
https://stackoverflow.com/questions/24922094/taking-a-git-diff-and-creating-a-new-branch-in-different-repo/24922587#24922587

using this, git can apply the diff for me, instead of me generating newFiles from oldFiles using diff.

idk if this still works after many commits (conflicts), I thought about replacing hunks/lines in versionSource with the ones specified in MY(not from git) diff.json file to generate versionGenerated
versionSource: for me,
versionGenerated: for PR,

to remove, I can replace with empty string, but it will create an empty line

[mark-wiemer]

You're right, for inline differences update-index won't be very helpful. My comment below should be more helpful

[mark-wiemer]

Another simple idea might be a clever use of git. Here's how it would work:

For the first PR:

1. Open a branch from the remote repo, no difference from the remote repo.
2. Make all the changes you want to customize your local filesystem (add files, remove files, make changes within files) all in one commit. This creates a commit with a hash value, call that value hash1
3. Make relevant changes for the PR
4. Before opening the PR, run git revert <hash1> where <hash1> is the hash of the commit from step 2.
5. Open the PR

For all subsequent PRs, you can:

1. Open a new branch
2. Run git cherry-pick <hash1> with the same hash mentioned before. This will create a new commit with the same changes as the previous commit. There may be merge conflicts, but they should be easy to resolve. Call this hash value hash2.
3. Make relevant changes for the PR
4. Before opening the PR, run git revert <hash2> where <hash2> is the hash of the newly-created commit from the new step 2.
5. Open the PR

If this seems promising, you can make it into a shell script so it's just one command to run each time you open a new PR. Try it out! Should be a lot less boilerplate than a VS Code extension.

If it doesn't sound good, that's OK :)

[FuPeiJiang]

ty, I don't understand yet, I will try this using a new test repo

[FuPeiJiang]

thank you, this works, I have to resolve conflicts when git revert AND git cherry-pick, I can currently resolve them "half automatically" using Meld Changes->Merge All merge strategy, this is annoying because I have to open the GUI, and Meld is slow to open. Can't Meld just merge it automatically ? It there another mergetool that can ? (using the same merge strategy)

found something to accelerate the process: it opens Meld with the file already merged. (I could ahk this, but this still opens GUI FOR EVERY CONFLICTED FILE, so slow): https://stackoverflow.com/questions/22225415/how-to-have-meld-as-git-mergetool-to-only-show-conflict-and-not-differences#57205652

[mergetool "meld"]
  cmd = meld --auto-merge "$LOCAL" "$BASE" "$REMOTE" --output "$MERGED"

---

this method works only for 1 commit of personal changes, I could squash many commits personal changes into 1, but... complicated...

---

this method produces too many commits just for back and forth , I'd like to keep a "diff file" on my personal branch, and generate a PR branch.

---

using a diff file will probably still cause merge conflics... I'd like to know how Meld:Merge All works, and does it work in every scenario ? (for this use case)

---

I will now look into git apply

[mark-wiemer]

I've never used Meld (or any git GUI), always the command line. VS Code has nice highlights and lens commands for merge conflicts:

Just click "Accept Current Change" to choose the top one or "Accept Incoming Change" for the bottom one. Worth exploring to quickly resolve conflicts. I don't think you should be consistently getting merge conflicts though. You will only get conflicts in files that have been changed in both the remote repo and your personal changes, and the files in the remote repo won't change that often, especially if they are settings files.

[FuPeiJiang]

this is the thing, it seems that Meld has a 4th merge option (Merge All) which is different from Accept Both Changes,
this merge strategy worked for every merge (but I rarely merge, so 3 times maximum).

does the command line have 4 merge options ?

[FuPeiJiang]

new idea,
con: uses 3 branches
dev, personal, squashed

generate branch by reverting ALL personal commits in dev branch. Instead of reverting 1 by 1, extract all personal commits (from dev), merge --squash these commits onto another branch (personal), then create PR branch from dev, while on PR branch, do git revert squashed

actually I don't extract, I just add personal commit to branch personal whenever I have a personal commit
so:
commit personal changes on dev.
git checkout personal
git cherry-pick dev to get the last personal commit

to generate PR branch:
git checkout squashed
git reset --hard <commit ID before any of personal changes>
git merge --squash personal
git commit
git checkout -b new_PR_branch_name
git revert squashed

but in this case I need to know which commits are personal BEFORE committing them.

I found a solution: I can remove personal changes after, and STILL add them as commits to branch personal
Since I don't want to change dev, I can just add commits to branch personal OR in dev, commit remove and revert OR
in dev, git commit --allow-empty

in branch dev, remove the personal changes
git commit -m "removed stuff_here"
git checkout personal
git revert dev
git checkout dev
git reset --hard "HEAD~"
now you can add an empty commit,

or, instead of reset --hard, you could git revert HEAD

to do these steps:
vscode extension ? or something else ?

2 extra branches take a bit of space
suggestions ?

[mark-wiemer]

This seems much closer to what I was originally suggesting, I think it should be easier to implement and understand than a VS Code extension. This looks really cool! Unfortunately I'm not following exactly how these steps will work, but if you have a working test project then it sounds good.

Since you want to execute a series of shell commands, I suggest writing a shell script to execute these steps. That way, whenever you want to create a PR branch, you can just run one custom command in your shell, like $ newahkpr (you choose the name), and you automagically have what you need!

If you're concerned about storage, I don't think two extra branches really takes up that much storage space. The repo is less than 2 MB right now, shouldn't be an issue to have a few extra personal branches. If you're worried about cognitive space, I think this is the simplest way to implement what you're suggesting. Over time, you will find the model becomes more intuitive and understood, I think, and you may find ways to shorten it even more. As long as you understand it, that's all the matters.

[FuPeiJiang]

the above didn't work..

is there ANY way to mark a list of commits to drop when generating a PR branch ?

I thought about ALWAYS starting personal commits with --p:

or tagging personal commits: but this would pollute my tag space: too many tags,
also, you can't have 2 tags with the same name

I could but idk where to feature request to git, to add a way to mark commits.

[mark-wiemer]

Unfortunately I never figured out exactly you're trying to do here. I remain convinced this problem could be solved with some atomic committing (making some commits 100% unwanted changes, making all other commits 100% wanted changes) and cherry-picking (picking only wanted commits) or rebasing (dropping all unwanted commits for your PR branch).

If you are able to, send a small snippet of:

1. Starting code
2. Some sample unwanted changes
3. Some sample wanted changes
4. The ideal final code to open in a PR

Maybe I can figure out a way to build a git history that easily allows dropping unwanted commits

[FuPeiJiang]

found no better solution
so, I've decided to always start personal commits with --p: and made some git aliases:
https://stackoverflow.com/questions/65877356/git-how-to-mark-commits-to-drop-for-generating-a-pr-branch/66509975#66509975