Git 2.44 Released - Can Yield Faster Pack Generation & Faster Rebases

[skeevy420]

I take the part of code I am actively editing outside the git repo. When I am done with the changes, I do a git pull in the repo to get the latest revision and do patch of my diff on the revision I have been working on. Sometimes this needs a bit manual intervention. Then test and submit. Diff and patch utilities are very useful with git. Hope this helps

copy/paste
git add .
git commit -am "you're lucky you're getting a commit message"

The workflow of champions

[mrg666]

copy/paste
git add .
git commit -am "you're lucky you're getting a commit message"

The workflow of champions

Yeah, copy/paste is enough for a single file. If there are more files changed and there are also other changes from the outside commits, diff/patch is the better way, at least for me. I am sure all people have their own workflow methods as there are so many ways to do things. One thing I feel strongly is that git is one of the most important pieces of software ever developed. I almost admire Linus Torvalds more for git than the Linux kernel.

[skeevy420]

I almost admire Linus Torvalds more for git than the Linux kernel.

Hear, hear.

[Weasel]

copy/paste
git add .
git commit -am "you're lucky you're getting a commit message"

The workflow of champions

Working with patches and diffs is actually a LOT easier for newbies or even for experienced people when they need to look or change things if there's a lot of boilerplate involved. Because you can script it with familiar file tools.

rediff can help too.

[uid313]

I take the part of code I am actively editing outside the git repo. When I am done with the changes, I do a git pull in the repo to get the latest revision and do patch of my diff on the revision I have been working on. Sometimes this needs a bit manual intervention. Then test and submit. Diff and patch utilities are very useful with git. Hope this helps

This sounds awfully clumsy and uncomfortable.

Because git doesn't know programming languages. It doesn't know if the changes in lines 10 or 90 are related or will break each other. All it knows is that two different changes have occurred on the same file. You have to push commit 10 to main, rebase the branch of commit 90, and then push commit 90 to main now that it knows about commit 10.

EDIT: To say that in a different way now that I've woke up and had some coffee, the way Git operates is by tracking the history of everything. Each commit is like adding a letter to the tracking alphabet so four commits would be A, B, C, and D. When you and someone else do work on the same file, Git doesn't know which commit, line 10 or line 90, should be E and which one should be F. It doesn't know how the two commits should be ordered for historical reasons nor does it know if you're reverting one commit or the other since the line 10 commit has the old line 90 and the line 90 commit has the old line 10. That old data is what is tripping everything up.

Pull 10
Rebase 90 with main
Pull 90

I hope that makes Git and issues like that make a bit more sense. You can freely swap 90 and 10 up there.

Pull 90
Rebase 10 with main
Pull 10

Thanks for the explanation.

With TFVC in Visual Studio on Windows you almost never get merge conflicts, and if you do, you can usually just click on the Auto-resolve button and it fixes it for you.
I am not saying TFVC is better than Git, because creating branches are heavy operations and uncomfortable, but the merge thing is much smoother.

[mrg666]

This sounds awfully clumsy and uncomfortable.

Lol, there is nothing comfortable with software development. It is all pain and sweat

[skeevy420]

Thanks for the explanation.

With TFVC in Visual Studio on Windows you almost never get merge conflicts, and if you do, you can usually just click on the Auto-resolve button and it fixes it for you.
I am not saying TFVC is better than Git, because creating branches are heavy operations and uncomfortable, but the merge thing is much smoother.

No problem. Git used to trip me up until I started thinking in Git.

I used to use the Git Cola UI and Meld for conflict resolution. All manual reviewing...which can be total pain in the ass when you're solving Java/C++ conflicts and you don't know Java/C++ .

If anyone here happened to have downloaded Android roms from me on XDA about a decade ago, that's what ya got

[direc85]

My tool of choice is Sublime Merge, with projects with other developers. It's not a free tool, but there's a trial period. You can do most common commit/merge/rebase/conflict-resolve actions without knowing git commands by heart (and then some, I think). For some flag combos you have to use the command line, but at that point things have gone a bit south already. It prints and backlogs errors (e.g. failed git hooks) nicely, too.

Seeing the changes, branches and "the flow" visually helped me so, so much when I actually actually had to learn git back in the day. So, after the trial I bought it. Now git is just another tool I don't have to "worry" about

TL;DR There are several great GUIs for git. Terminal is not the only way to use git these days.