3 ms·

git-diff doesn't require you to do gymnastics to compare files from different branches It requires me to use git-diff. How do I do it without involving the VCS

git-diff doesn't require you to do gymnastics to compare files from different branches It requires me to use git-diff. How do I do it without involving the VCS tool? How do I get both files side-by-side in Emacs so I can go through them thoroughly (some of us prefer that to reading diffs, you know)? Since you can reconstruct deleted branches, I don't see the problem with deleting them. I want the history of my codebase to be easy to get a feel for; that means major work (e.g., a long-lived branch which made significant changes) should be easily accessible. Telling people to hunt down the right merge commit and work back through its ancestry doesn't do that. Inventing ad-hoc schemes of tags or renamed branches to try to make up for the inability to keep a branch but say you're done with it doesn't do that. It reminded me of why I like git so much. Meanwhile, it's (one reason) why I don't like git so much.

hyperbolist 17y ago
How do I get both files side-by-side in Emacs so I can go through them thoroughly (some of us prefer that to reading diffs, you know)? git show branch:path/to/file > /tmp/file I want the history of my codebase to be easy to get a feel for So never delete branches. You'll know if they're "done" if they've been merged into your master branch.
- ubernostrum 17y ago
  git show Did you miss the part where I said I'd like to not involve the VCS tool? Without using git, how do I see two different branches' versions of files? So never delete branches. You'll know if they're "done" if they've been merged into your master branch. But nobody else will. What everybody and their brother has told me to do is delete the branch and invent an ad-hoc naming scheme to tag the merge commits. Which is... um, no, that's not the same as being able to close a branch.
  - hyperbolist 17y ago
    how do I see two different branches' versions of files? You could clone the branches to different paths, I guess. But nobody else will [know that a branch is "done".] If you've instructed the team to care about merged status, they will. And there's nothing semantically strange about it either. I get it, git isn't for you. I concede.
fr0sty 17y ago
GIT_EXTERNAL_DIFF lets you use emacs as your diff tool. http://stackoverflow.com/questions/255202/how-do-i-view-git-diff-output-with-visual-diff-program http://stackoverflow.com/questions/255202/how-do-i-view-git-...

hyperbolist 17y ago

How do I get both files side-by-side in Emacs so I can go through them thoroughly (some of us prefer that to reading diffs, you know)? git show branch:path/to/file > /tmp/file I want the history of my codebase to be easy to get a feel for So never delete branches. You'll know if they're "done" if they've been merged into your master branch.

ubernostrum 17y ago
git show Did you miss the part where I said I'd like to not involve the VCS tool? Without using git, how do I see two different branches' versions of files? So never delete branches. You'll know if they're "done" if they've been merged into your master branch. But nobody else will. What everybody and their brother has told me to do is delete the branch and invent an ad-hoc naming scheme to tag the merge commits. Which is... um, no, that's not the same as being able to close a branch.
- hyperbolist 17y ago
  how do I see two different branches' versions of files? You could clone the branches to different paths, I guess. But nobody else will [know that a branch is "done".] If you've instructed the team to care about merged status, they will. And there's nothing semantically strange about it either. I get it, git isn't for you. I concede.

fr0sty 17y ago

GIT_EXTERNAL_DIFF lets you use emacs as your diff tool. http://stackoverflow.com/questions/255202/how-do-i-view-git-diff-output-with-visual-diff-program http://stackoverflow.com/questions/255202/how-do-i-view-git-...