3 ms·

I've always found the git CLI really odd. For example, when doing a git diff, how would anyone use the following information that gets printed out? new file mo

by j2kun 13y ago

I've always found the git CLI really odd. For example, when doing a git diff, how would anyone use the following information that gets printed out? new file mode 100644 index 0000000..cfbc74a And you have all of these symbols that show up in the diff like "+[m" before a new line (why not just +?). I imagine there are good reasons for all of this, but I also feel like some of this should be hidden behind a --verbose flag or something.

eggnet 13y ago
Having git emit, by default, a diff that can't reliably be used by git to patch another repository seems ill advised.
phaker 13y ago
Do you mean you get '+[m' instead of '+' in front of an added line? If so, this looks suspiciously like ecma formatting escapes (\e[XXXm). Try if calling git diff --no-color, if this helps then something is broken on your setup. Another way i could see that happening is if you have color set to 'always' and then use some app that wraps git's command line output.
- deleted 13y ago
  [deleted]
- as_someone 13y ago
  j2kun means the stuff that shows up from TFA when using git diff: diff --git a/octocat.txt b/octocat.txt index 7d8d808..e725ef6 100644 --- a/octocat.txt +++ b/octocat.txt @@ -1 +1 @@ -A Tale of Two Octocats +[mA Tale of Two Octocats and an Octodog
  - pmh 13y ago
    phaker is correct, that's just an escape sequence that the JS terminal didn't handle (or handled incorrectly). Using --no-color you get: diff --git a/octocat.txt b/octocat.txt index 7d8d808..e725ef6 100644 --- a/octocat.txt +++ b/octocat.txt @@ -1 +1 @@ -A Tale of Two Octocats +A Tale of Two Octocats and an Octodog
prezjordan 13y ago
Because git-diff produces a full patch [1] that can be applied to a file. It's a lot more than just showing lines added/lines removed. The two hashes are useful because it shows what two objects are being compared. It's the same as saying "Change #12 vs Change #13" (not really, but sorta). [1]: http://linux.die.net/man/1/patch http://linux.die.net/man/1/patch
- j2kun 13y ago
  So the use case is primarily to produce something machine readable rather than human readable (it's not that unreadable, but still). I can see that. Is there a human-readable flag?

by j2kun 13y ago

eggnet 13y ago

Having git emit, by default, a diff that can't reliably be used by git to patch another repository seems ill advised.

phaker 13y ago

Do you mean you get '+[m' instead of '+' in front of an added line? If so, this looks suspiciously like ecma formatting escapes (\e[XXXm). Try if calling git diff --no-color, if this helps then something is broken on your setup. Another way i could see that happening is if you have color set to 'always' and then use some app that wraps git's command line output.

deleted 13y ago
[deleted]
as_someone 13y ago
j2kun means the stuff that shows up from TFA when using git diff: diff --git a/octocat.txt b/octocat.txt index 7d8d808..e725ef6 100644 --- a/octocat.txt +++ b/octocat.txt @@ -1 +1 @@ -A Tale of Two Octocats +[mA Tale of Two Octocats and an Octodog
- pmh 13y ago
  phaker is correct, that's just an escape sequence that the JS terminal didn't handle (or handled incorrectly). Using --no-color you get: diff --git a/octocat.txt b/octocat.txt index 7d8d808..e725ef6 100644 --- a/octocat.txt +++ b/octocat.txt @@ -1 +1 @@ -A Tale of Two Octocats +A Tale of Two Octocats and an Octodog

prezjordan 13y ago

Because git-diff produces a full patch [1] that can be applied to a file. It's a lot more than just showing lines added/lines removed. The two hashes are useful because it shows what two objects are being compared. It's the same as saying "Change #12 vs Change #13" (not really, but sorta). [1]: http://linux.die.net/man/1/patch http://linux.die.net/man/1/patch

j2kun 13y ago
So the use case is primarily to produce something machine readable rather than human readable (it's not that unreadable, but still). I can see that. Is there a human-readable flag?