Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • direc85
    replied
    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.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by uid313 View Post

    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

    Leave a comment:


  • mrg666
    replied
    Originally posted by uid313 View Post

    This sounds awfully clumsy and uncomfortable.
    Lol, there is nothing comfortable with software development. It is all pain and sweat

    Leave a comment:


  • uid313
    replied
    Originally posted by mrg666 View Post

    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.

    Originally posted by skeevy420 View Post

    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.

    Leave a comment:


  • Weasel
    replied
    Originally posted by skeevy420 View Post

    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.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by mrg666 View Post
    I almost admire Linus Torvalds more for git than the Linux kernel.
    Hear, hear.

    Leave a comment:


  • mrg666
    replied
    Originally posted by skeevy420 View Post

    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.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by mrg666 View Post

    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

    Leave a comment:


  • skeevy420
    replied
    Originally posted by uid313 View Post

    Maybe, because they need it too, they don't understand it either.

    I do a git pull and git fetch or whatever and I get a merge conflict because someone edited line 10 and I edited line 90. It is stupid. Okay if we both edited the same line, then sure we got a merge conflict, but this is silly.

    I try get a git pull or git fetch or whatever and Git says no you cant do that, you must configure fast forward or merge or rebase or something, I don't know. Why Git asking me this stupid questions? I don't know the difference and I don't want to pick anything, and I don't care, just give me some sane defaults.
    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​
    Last edited by skeevy420; 25 February 2024, 10:57 AM.

    Leave a comment:


  • mrg666
    replied
    Originally posted by uid313 View Post

    Maybe, because they need it too, they don't understand it either.

    I do a git pull and git fetch or whatever and I get a merge conflict because someone edited line 10 and I edited line 90. It is stupid. Okay if we both edited the same line, then sure we got a merge conflict, but this is silly.

    I try get a git pull or git fetch or whatever and Git says no you cant do that, you must configure fast forward or merge or rebase or something, I don't know. Why Git asking me this stupid questions? I don't know the difference and I don't want to pick anything, and I don't care, just give me some sane defaults.
    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

    Leave a comment:

Working...
X