[git-users] git-apply: do not show *inherited* whitespace errors?

2016-12-22 Thread Igor Djordjevic
Hi to all,

I`m using Git for Windows mainly for now, where the issue is probably more 
(or only) pronounced, yet I kind of feel this might be of interest across 
platforms (for Git in general), as it makes cross-platform collaboration 
harder than it needs to be (or so it seems to me). I`m posting here and not 
on the main Git mailing list as this topic might be very well elaborated 
till now, so not to produce unnecessary noise there.

When creating a patch, Git exports line endings as they are in the file 
(usually CR+LF on Windows), yet when you apply the patch, it warns you of 
"whitespace errors" (caused by CR part) - even though no whitespace 
actually changed (both old and new hunk have the same CR+LF line endings).

Now, I may understand that in Unix world there was a need to consider 
anything other than LF line ending a "whitespace error" which should be 
reported accordingly, but with Git being widely used across platforms 
nowadays it seems it should know a bit better now, especially when line 
endings *didn`t change in the first place*.

But even worse, if I change the patch file line endings manually to LF and 
git-apply the patch like that - no warning is given, even though line 
endings are in fact different now!

I`m aware of --ws-error-highlight setting for git-diff, allowing to 
show/compare line endings between old/new lines, but manual line comparison 
seems rather impractical in case of applying multiple patches - and yet 
real whitespace errors (actually introduced with the patch we`re applying) 
are lost in the noise (or worse, not even reported, as in CR+LF to LF 
conversion).

Current git-apply --whitespace options seem to allow for a variety of 
settings, but none to warn about *new* whitespace errors *only*, or even 
more important - about line ending changes in general (as converting from 
CRLF to LF might be considered a whitespace error situation, even though 
general Git thinks differently at the moment, probably assuming you 
actually corrected an existing whitespace error... :P).

So, what are the thoughts on this? Would having an additional --whitespace 
option (like "preserve", "warn-new", "warn-changed", or something) to warn 
about *new* whitespace errors *only* make sense in general? Seems so to me, 
but yet as I`m still new around, I might be missing a bigger picture...

p.s. Please let me know if you think this should be reposted to main Git 
mailing list (or to Git for Windows one, even).

Thanks, BugA

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [git-users] fetched to wrong branch

2016-12-22 Thread Pablo Rodríguez
On 12/20/2016 08:04 AM, Konstantin Khomoutov wrote:
> On Mon, 19 Dec 2016 17:43:18 +0100 Pablo Rodríguez wrote:
> 
>> I have a local repository and a remote at GitHub. My local repo had a
>> master branch and the remote had only a gh-pages branch.
>>
>> I wanted to pull from my gh-pages remote branch (with "git pull origin
>> gh-pages"). I was about to commit on the master branch and I realized
>> I had no local gh-pages branch. So I put a blank message, to avoid
>> commiting to the master branch.
>>
>> I unstaged the changes with "git reset HEAD", but how can I remove the
>> already fetched files. I mean, is there something I have to do after
>> unstaging the fetched files?
> 
> I'm not sure I understood the course of actions but can you elaborate
> on your current situation?  Precisely, when you "unstaged the changes"
> -- are those "extraneous" files you asking about now untracked or
> tracked with unstaged changes?
> 
> Copying an pasting the output of running
> 
>   git status
> 
> would help immensely.

Many thanks for your reply, Konstantin.

This is what I get:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add ..." to include in what will be committed)

Cousine-Bold.ttf
Cousine-BoldItalic.ttf
Cousine-Italic.ttf
Cousine-Regular.ttf
website/

nothing added to commit but untracked files present (use "git add"
to track)

I guess the files are untracked. BTW, unstaging head doesn’t mean
untracking files that were stagged for next commit?

But are the files somehow in my local master branch?

Many thanks for your help,

Pablo
-- 
http://www.ousia.tk

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [git-users] fetched to wrong branch

2016-12-22 Thread Pablo Rodríguez
On 12/19/2016 06:04 PM, John McKown wrote:
> On Mon, Dec 19, 2016 at 10:43 AM, Pablo Rodríguez wrote:
> [...]
> I wanted to pull from my gh-pages remote branch (with "git pull origin
> gh-pages"). I was about to commit on the master branch and I realized I
> had no local gh-pages branch. So I put a blank message, to avoid
> commiting to the master branch.
> 
> I unstaged the changes with "git reset HEAD", but how can I remove the
> already fetched files. I mean, is there something I have to do after
> unstaging the fetched files?
> 
> ​If I understand you correctly, you want to delete the gh-pages branch
> from "origin" which you accidentally got via a "git fetch"?​

Many thanks for your reply, John,

Sorry, I’m afraid I haven’t explained myself acurately.

Maybe the steps and a final question would be clearer:

1. git pull origin gh-pages
(I ignored that I was pulling to my local master branch.)
2. I left commit comment empty, so no commit was done.
3. git reset HEAD
(I wanted to unstage the fetched files.)

Are the fetched files somewhere in my local master branch?

Many thanks for your help,

Pablo
-- 
http://www.ousia.tk

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [git-users] Re: git filters PATH

2016-12-22 Thread Michael

On 2016-12-22, at 12:33 AM, Oded Badt  wrote:

> Update: A coworker found a workaround to my original question:
> 
> [filter "remove_outputs"]
>   clean = /bin/sh -c '$PWD/remove_outputs'
> smudge = cat
> 
> Works as long as remove_outputs is in the repo root and thats where you run 
> your git commands

What if you run git commands from deep inside the git repository, i.e., if you 
"live" down in src/java/main/ and have a bunch of class files down there?

Does git have a "$GIT_ROOT" that it exports? If not, would this be a good thing 
to add?

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[git-users] Re: git filters PATH

2016-12-22 Thread Oded Badt
Update: A coworker found a workaround to my original question:

[filter "remove_outputs"]
clean = */bin/sh -c '$PWD/remove_outputs'*
smudge = cat

Works as long as *remove_outputs* is in the repo root and thats where you 
run your git commands

However, I encountered a larger problem: git config properties cannot be 
kept in the repo so they are not cloned anyway, which kind or renders my 
original question redundant.

Can anyone thing of a workaround my original problem?

Thanks!
   Oded  

On Wednesday, December 21, 2016 at 7:49:11 PM UTC+2, Oded Badt wrote:
>
> Hey, I'm looking for a way for git to find a filter (clean / smudge/ etc ) 
> that is in the root folder of the git repo. I cannot know in advance what 
> the absolute dir of the repos would be and I prefer not to place it maually 
> in the PATH for every clone. Cant anyone think of an idea?
>
> Specifically, it is a python script that does some json manipulation, so 
> sed regexping would be very hard
>
> Any ideas?
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.