Re: [git-users] untracked files not shown when using 'git status'

2015-11-29 Thread Matthew Johnson 
I would say that is not as documented. Why? Because "Shows untracked files 
and directories" does not give any conditioning limiting which untracked 
files it will show: one would then think it means to show all untracked 
files, including those in untracked directories.

On Friday, November 27, 2015 at 8:33:36 AM UTC-8, Konstantin Khomoutov 
wrote:
>
> On Fri, 27 Nov 2015 08:16:30 -0800 (PST) 
> Kurt Vermeiren  wrote: 
>
> > In our project we have 4 untracked files, for local development. 
> > 
> > Output of *git status *: 
> > 
> > Untracked files: 
> >   (use "git add ..." to include in what will be committed) 
> > 
> > sdb-batch-web/src/main/webapp/WEB-INF/jboss-web.xml 
> > sdb-ear/src/main/application/ 
> > sdb-services/src/main/webapp/WEB-INF/jboss-web.xml 
> > sdb-web/src/main/webapp/WEB-INF/jboss-web.xml 
> > 
> > Note the second line, only the directory is shown. 
> > 
> > Output of *git status --untracked-files *: 
> > 
> > Untracked files: 
> >   (use "git add ..." to include in what will be committed) 
> > 
> > sdb-batch-web/src/main/webapp/WEB-INF/jboss-web.xml 
> > sdb-ear/src/main/application/META-INF/jboss-deployment-structure.xml 
> > sdb-services/src/main/webapp/WEB-INF/jboss-web.xml 
> > sdb-web/src/main/webapp/WEB-INF/jboss-web.xml 
> > 
> > What is the difference between both commands, our believe is the 
> > output should be identical. 
> > 
> > We are on 2.6.3, OS is Ubuntu 14.04 LTS 
>
> I'd say it behaves as documented. 
>
> What does 
>
>   ls -R sdb-ear/src/main/application/ 
>
> show? 
>
> I bet it will show a single directory "META-INF" in it, 
> and a single file "jboss-deployment-structure.xml" in that one, right? 
>
> Let me cite the `git status` manual page: 
>
> | -u[], --untracked-files[=] 
> | Show untracked files. 
> | 
> | The mode parameter is optional (defaults to all), and is 
> | used to specify the handling of untracked files. 
> | 
> | The possible options are: 
> | ·   no - Show no untracked files. 
> | ·   normal - Shows untracked files and directories. 
> | ·   all - Also shows individual files in untracked 
>   directories. 
> | 
> | When -u option is not used, untracked files and 
> | directories are shown (i.e. the same as specifying normal), to help 
> | you avoid forgetting to add newly created files. Because it takes 
> | extra work to find untracked files in the filesystem, this mode may 
> | take some time in a large working tree. You can use no to have git 
> | status return more quickly without showing untracked files. 
> | 
> | The default can be changed using the status.showUntrackedFiles 
> | configuration variable documented in git-config(1). 
>
> So basically when you doesn't specify the --untracked-files 
> command-line option, `git status` behaves as if you have passed 
> --untracked-files=normal and if everything is untracked in a directory, 
> the output is reduced to name just that directory. 
> When you pass --untracked-files, it gets interpreted as 
> --untracked-files=all, and you see the untracked files under a 
> completely untracked directory. 
>
> I reckon the rationale for this default behaviour is that an untracked 
> directory might be huge and if you won't track anything in it, there's 
> no point in listing all the garbage it contains.  Conversely, if you 
> have a directory which has some of its contents tracked, it's sensible 
> to show you what exactly is not tracked in there -- because most 
> probably it's newly created files. 
>

-- 
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: Issue with exorbitant number of non-sensical conflicts following a second git rebase on branch

2014-07-06 Thread Matthew Johnson 
Doing minor commits where you don't want a branch -- but why wouldn't you 
want a branch? One of the great excellent points of Git is supposed to be 
that it makes branching so much easier, you can do branches in Git where 
you would never do it in SVN or any other version management system.

As for your three use cases where you recommend rebase, how will you 
prevent the problem described in the book if someone else has also worked 
on that branch? And what do you mean by clean up commits anyway? It is 
not at all clear from your description whether you think these use cases 
avoid rebasing pushes to a common repo, or you just don't think that is 
important; but how else can you avoid having to re-merge commits?

The book may be old fashioned, but it was written by one of the inventors 
of Git (I realize Torvalds did a lot of it too), which among other factors 
makes it likely that his old fashioned approach has unappreciated 
advantages over 'newer' approaches.

Personally, I am especially wary of newer approaches after seeing how 
some young CS grads thought they were being clever by inventing a new 
workflow that involved the frequent use of the patch command -- they never 
figured out how much of their grief was caused by their misunderstanding of 
how to use Git.

There are further comments interspersed below.

On Sunday, July 6, 2014 3:05:50 AM UTC-7, Thomas Ferris Nicolaisen wrote:

 On Saturday, July 5, 2014 7:33:12 AM UTC+2, Matthew Johnson wrote:

 I usually only 'lurk' on this forum, since I am pretty new to Git myself, 
 too. But there are two things that stood out here I feel I need to speak up 
 about: 1) be very, very careful about following the 'guidance' from a Stack 
 Overflow post where neither the question nor any of the answers got a 
 rating higher than 3 2) rebase is NOT part of the normal Git workflow. Its 
 use should be rather rare. I cannot imagine why you would want to do it 
 after every checkout.


 I agree, I would personally only bother doing it every once in a while, 
 due to the overhead work. However, the more often you do it, the smaller 
 amount of conflicts you'll have to deal with at a time. In a busy 
 repository, it could be the right thing to do.


But you also get a smaler amount of conflicts if you do frequent merges. 
And merges have the advantage that they do not throw away commits creating 
look-alikes to fool your collaborators. 

  


 In particular, the man page for git-rebase (recall that to look up git 
 commands in man, you need to add the '-') has two warnings that are likely 
 quite pertinent.

 1) Rebasing (or any other form of rewriting) a branch that others have 
 based work on is a bad idea


 As long as thread-starter is the only one using this feature branch in the 
 shared repository, it should be all right.


But in a busy repository, you cannot count on that. On the contrary: in a 
busy repository it is easy to miss someone working on the same code -- 
until he shows up in a merge.

  

 Taking a slightly different approach, the online Git book covering rebase 
 (http://git-scm.com/book/en/Git-Branching-Rebasing 
 http://www.google.com/url?q=http%3A%2F%2Fgit-scm.com%2Fbook%2Fen%2FGit-Branching-Rebasingsa=Dsntz=1usg=AFQjCNHmAubPITlKFW927EdqbpVTDVCzHA)
  
 seems to imply that if what you want to do can be easily done with merge, 
 then you should do so, resorting to rebase only when you want to do odd 
 things like apply not the whole current branch, but only a patch in it to 
 another branch.


 I think that's a bit old-fashioned view on things. I think we're better 
 off embracing rebase as a tool earlier than later, teaching new users how 
 and when to use it appropriately. There are several use-cases for rebase 
 that I would classify as normal procedure:

 * Doing minor commits on master for which you don't want a branch: git 
 pull --rebase
 * Starting off on branches that you end up wanting to just rebase on 
 master instead (and fast-forward onto master)
 * Rebase interactive to clean up commits


-- 
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: Issue with exorbitant number of non-sensical conflicts following a second git rebase on branch

2014-07-04 Thread Matthew Johnson 
I usually only 'lurk' on this forum, since I am pretty new to Git myself, 
too. But there are two things that stood out here I feel I need to speak up 
about: 1) be very, very careful about following the 'guidance' from a Stack 
Overflow post where neither the question nor any of the answers got a 
rating higher than 3 2) rebase is NOT part of the normal Git workflow. Its 
use should be rather rare. I cannot imagine why you would want to do it 
after every checkout.

In particular, the man page for git-rebase (recall that to look up git 
commands in man, you need to add the '-') has two warnings that are likely 
quite pertinent.

1) Rebasing (or any other form of rewriting) a branch that others have 
based work on is a bad idea
2) You should understand the implications of using git rebase on a 
repository that you share.

Those implications can be rather complicated, as the length of the man page 
attests.

Taking a slightly different approach, the online Git book covering rebase 
(http://git-scm.com/book/en/Git-Branching-Rebasing) seems to imply that if 
what you want to do can be easily done with merge, then you should do so, 
resorting to rebase only when you want to do odd things like apply not the 
whole current branch, but only a patch in it to another branch.

I have never had to use rebase yet, but before I do, I will read that whole 
chapter. I heartily recommend you do the same, especially since one of the 
sections is (sub)titled, The Perils of Rebasing.


On Friday, July 4, 2014 1:11:57 AM UTC-7, ayrshi...@gmail.com wrote:

 I am fairly new to the concept of rebasing with Git, and I have been 
 following the guidance from a StackOverflow post 
 http://stackoverflow.com/questions/22412444/local-git-branch-has-diverged-from-origin-following-an-interactive-rebase
  
 by doing this:

  git fetch
 git checkout CRM-my-feature-branch
 git rebase -i origin/develop
 git push -f origin CRM-my-feature-branch

 This has generally worked well for me. I done this in mid-May to bring 
 CRM-my-feature-branch up to date with origin/develop which other developers 
 are working on.

 However, I have just tried to do the same thing again and I have been hit 
 with a vast number of conflicts. Now, conflicts are fine but some files 
 seem to almost be in a permanent state of conflict. For example, commit 2 
 will show as a conflict of commit 1 so rather than git realising that 
 commit 2 comes after commit 1 - it shows as a conflict.

 Is this a symptom of rebasing on top of a branch that I have previously 
 rebased on?


-- 
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 diff not showing details

2013-10-06 Thread Matthew Johnson 
Ah, so contrary to an earlier assertion in this thread, Git and Git diff 
command specifically DO understand Unicode -- just not in the outdated 
UTF-16 transformation format.

On Sunday, October 6, 2013 9:49:12 AM UTC-7, Peter Pitchford wrote:

 It turns out git diff doesn't understand utf-16 encoded files. The clue is 
 that the output says Binary files 
 I switched the encoding to utf-8 and git diff now shows the details. 

  UTF-16 is a historical accident that persists mainly due to inertia. 
 UTF-16 has no practical advantages over UTF-8, and it is worse in some 
 ways. 
 http://benlynn.blogspot.com/2011/02/utf-8-good-utf-16-bad_07.html
 I never knew that. 

 On Sunday, October 6, 2013 11:15:44 AM UTC-4, Peter Pitchford wrote:

 Windows 7
 Git Bash or Command line, both act the same.

 When I change a file and then run *git diff* I get: 
 C:\workshop\gitgit diff
 diff --git a/thirdfile.txt b/thirdfile.txt
 index 7caac66..f6eb45c 100644
 Binary files a/thirdfile.txt and b/thirdfile.txt differ

 How do I get it to show the lines that have been changed? 



-- 
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/groups/opt_out.

Re: [git-users] Re: Humorous description of git

2013-06-17 Thread Matthew Johnson 
It isn't true. The claim that Git reduces to branches being endofunctors on 
submanifolds of Hilbert spaces is humorous.

After all, one thing I see was overlooked in the attempt to actually make 
sense out of it, looking at definitions, was that there is no notion of 
continuity in Git; but continuity is absolutely essential for 
homeomorphisms (except in graph theory: but that definition does not make 
sense here either). Nor is there a notion corresponding to the fundamental 
form of the Hilbert space.

That said, some of the parallels are highly suggestive. But any 
mathematical description of the fundamentals of Git is going to have to 
rely primarily on discrete mathematics, NOT topology, differential geometry 
or functional analysis.

On Monday, June 17, 2013 2:20:42 PM UTC-7, Philip Oakley wrote:

  - Original Message - 

 *From:* Joe Cabezas javascript: 
 *To:* git-...@googlegroups.com javascript: 
 *Cc:* Eric Gorr javascript: 
 *Sent:* Monday, June 17, 2013 9:05 PM
 *Subject:* Re: [git-users] Re: Humorous description of git

 oh god!, nice to see you have spare time philip! :D

 At the moment I'm off sick, coughing and spluttering, so this passes the 
 time...
 Glad you liked it. Just need to read why a DAG==Hilbert Space now ;-)

  2013/6/17 Philip Oakley philip...@iee.org javascript:

 ** 
 *homeomorphic = a one-to-one correspondence, continuous in both 
 directions, between the points of two geometric figures or between two 
 topological spaces. So I think that means if my SHA1 equals your SHA1 we 
 have the same commit, so the same commit tree and DAG, all the way back to 
 all the root commits.*
 ** 
 *Endofunctor*: A functor that maps a category to itself. [commit links 
 to - maps to commit]  http://en.wikipedia.org/wiki/Functor
 Mapping: a direct co-respondance between one item and another. (can be 
 one way, like streets)
  
 submanifolds:  *submanifold* of a 
 manifoldhttp://en.wikipedia.org/wiki/Manifold
  *M* is a subset http://en.wikipedia.org/wiki/Subset *S* which itself 
 has the structure of a manifold, [Git is branches all the way down. No 
 branch is special. These be branches, which link backwards and possibly 
 join up with other branches at forks]
  
 [Manifold: a *manifold* is a topological 
 spacehttp://en.wikipedia.org/wiki/Topological_space
  that near each point resembles Euclidean 
 spacehttp://en.wikipedia.org/wiki/Euclidean_space. 

 Topological means the mathematicians have bent it a bit, Euclidean means 
 its it looks all straight with square corners again if you don't look too 
 far, e.g. an exhaust manifold of an engine is effectively the same as a 
 straight pipe]
 That is, lines of development are locally straight, no matter what the 
 --graph option shows!
  
 A *Hilbert space* *H* is a realhttps://en.wikipedia.org/wiki/Real_number
  or complex https://en.wikipedia.org/wiki/Complex_number inner product 
 space https://en.wikipedia.org/wiki/Inner_product_space that is also a 
 complete 
 metric space https://en.wikipedia.org/wiki/Complete_metric_space with 
 respect to the distance function induced by the inner product.
 i.e. a 'space' and a 'product' (function between two items) (that measure 
 a 'distance') that can 'completely' measure everywhere in the space. i.e. 
 things add up properly and no wormholes in space.
  
 found Every directed graph defines a Hilbert space ... 
 http://www.austms.org.au/Publ/Jamsa/V82P3/l112.html so it must be true.
  
 So it all sounds true and plausible. It means that many and various 
 mathematical (and hence computer science) theories continue to be true in 
 the general case and there are no nasty special cases as long as we stick 
 with the basic git data model - long live those homeomorphic 
 endofunctors mapping submanifolds of a Hilbert space!
  
 A bit more fun education, let it waft over you.
  
 Philip
  

  - Original Message - 
 *From:* Eric Gorr javascript: 
  *To:* git-...@googlegroups.com javascript: 
 *Cc:* Philip Oakley javascript: 
 *Sent:* Monday, June 17, 2013 11:42 AM
 *Subject:* Re: [git-users] Re: Humorous description of git

 I to would like to see a translation...

 On Monday, June 17, 2013 3:25:02 AM UTC-4, Philip Oakley wrote: 

  But waht we need is the 'translation' as to why it's true ;)
  
 I see that homeomorphic = a one-to-one correspondence, continuous in 
 both directions, between the points of two geometric figures or between two 
 topological spaces. So I think that means if my SHA1 equals your SHA1 we 
 have the same commit tree and DAG.
  
 I'm guessing the sub-manifolds is about branches.
  
 Any more suggestions?
  
 Philip

 - Original Message - 
 *From:* Eric Gorr 
 *To:* git-...@googlegroups.com 
 *Sent:* Monday, June 17, 2013 2:40 AM
 *Subject:* [git-users] Re: Humorous description of git

 Randomly came across it again...if anyone is interested...

Re: [git-users] Why Same Files show up with different Statuses in Git?

2013-01-31 Thread Matthew Johnson 
git config --list does not show core.filemode at all. Nor does git 
config --get core.filemode (both in Cygwin/windows). So what does it 
default to?

On Wednesday, January 30, 2013 10:03:47 PM UTC-8, Blind wrote:

 Just out of curiosity, what you have as filemode configuration?
 Maybe if you do 

 $git config core.filemode false

 the files will no longer show as modified?

 31 януари 2013, четвъртък, 03:40:58 UTC+2, Matthew Johnson написа:

 What differences does it display? It lists about a hundred .ogg files 
 (like the one I included) as 'modified'. I did not want to burden the group 
 with the whole list, so I mentioned only one .ogg file. But here are the 
 first few lines, which include ogg, jpb, and png files:

 [mejohnsn@localhostThinkpad mr.ed]$ git status
 # On branch master
 # Changes not staged for commit:
 #   (use git add file... to update what will be committed)
 #   (use git checkout -- file... to discard changes in working 
 directory)
 #
 #   modified:   fix_ogg.py
 #   modified:   lesson1/images/home-icon.jpg
 #   modified:   lesson1/images/home-icon.png
 #   modified:   lesson1/images/left-arrow.png
 #   modified:   lesson1/images/right-arrow.png
 #   modified:   lesson2/images/home-icon.jpg
 #   modified:   lesson3/images/home-icon.jpg
 #   modified:   lesson3/lesson_a/images/home-icon.jpg
 #   modified:   lesson3/lesson_a/sounds/1.ogg
 #   modified:   lesson3/lesson_a/sounds/10.ogg
 ...

 It even includes one Python file I forgot to mention since I have no 
 intention of checking it into the repository;)

 None of these show up as modified when I type the same git status in a 
 Cygwin command line.

 On Wednesday, January 30, 2013 8:21:37 AM UTC-8, Dale Worley wrote:

  From: Matthew Johnson mejo...@gmail.com 
  
  Under Windows (cygwin) git status shows nothing to commit, only 
 untracked 
  files, which is what I expect; only under F17 do I get several 
 modified 
  files -- and these have old dates (e.g. Nov 27). 

 My guess is that it has something to do with line-endings or some 
 subtlety about how file modification times are handled. 

 Under F17, when you do a git diff, what differences does it display? 

 Dale 



-- 
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/groups/opt_out.

Re: [git-users] Re: Why Same Files show up with different Statuses in Git?

2013-01-31 Thread Matthew Johnson 
Hi, Philip-

Thanks for the response.

Which 'settings' are you talking about? I am only aware of those referred 
to by git config --list, and I don't see anything that would explain it 
-- especially not in Cygwin/Windows, where only user.name and user.email 
are set. Yet it is from Cygwin I have done all my submits and pushes (until 
I resolve the discrepancy, I am not going to risk executing it commands 
from Fedora).

BTW: your phrase work tree files in the two OS's makes it sound like you 
are assuming I have two different workspaces under the two OSs. What I 
really have is one worskpace directory viewed either under Windows/Cygwin 
or with the same partition mounted on a filesystem under Fedora. So the 
files are exactly the same, though Cygwin does funny things with 
representing permissions, which might turn out to be relevant here. Does 
Git consider a file 'modified' if only the permissions are changed?

Finally, the Git Book admits that plumbing commands are not meant for the 
average user or even really for the command line, so more specific guidance 
(if plumbing is really the way to go) would certainly be needed: which 
plumbing commands? Is there one which will tell me why it considers a given 
file modified?

On Thursday, January 31, 2013 12:11:02 AM UTC-8, Philip Oakley wrote:

  Given what you say about your .ogg file, it is probable that git's 
 heuristic thinks they are [in some cases] binary (perhaps they are unicode 
 files which will contain Null bytes) and won't therefore convert the line 
 endings.
  
 The Git for Windows and Linux version of Git have slightly different 
 default settings, so do check what they are. The line [EOL] and file [EOF] 
 ending converstion discussions are spread over two or three man pages, and 
 do take a bit of time to appreciate all the different normalisation issues.
  
 You can also try expanding the repo's blobs (using plumbing commands), and 
 comparing those to the work tree files in the two OS's to which bytes are 
 being changed, and in which direction.
  
 Philip

 - Original Message - 
 *From:* Matthew Johnson javascript: 
 *To:* git-...@googlegroups.com javascript: 
 *Sent:* Thursday, January 31, 2013 1:22 AM
 *Subject:* [git-users] Re: Why Same Files show up with different Statuses 
 in Git?

 Good guess, I had not been thinking about the different EOLs, but all the 
 files that show up as modified only under Fedora are .ogg files: no EOLs at 
 all. Even weirder, the textual files, whether HTML or JavaScript, do not 
 have this problem. So it is hard to see how EOL inconcistency could explain 
 why sound files are showing up as modified.

 On Wednesday, January 30, 2013 11:30:28 AM UTC-8, Alex Lewis wrote: 

 I think this question on stackoverflow might help... - 
 http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git
  

 Basically the problems stems to you using the same physical repo with two 
 different types of Git client, one built to use Windows EOL and the other 
 using Linux EOL. When you mix the two, I.e. work with a file in Linux when 
 it was created whilst on Windows I think you'll run into problems. I think 
 if you set up the Windows client correctly (or specifically use the 
 .gitattributes file for the repository) I *think* you'll be ok. 

 HTH

 On Wednesday, 30 January 2013 02:40:47 UTC, Matthew Johnson wrote: 

 I hate to cross post, but I can no longer see my message to the same 
 effect at the Git mailing list, where I got no reply, so here we go: 

 First, some background. I have one hard disk separated into two partitions: 
 one for the version of Windows 7 that shipped on this rather new 
 Thinkpad (Windows 7 Professional SP1), the other for Fedora 17 (which I 
 installed and keep up-to-date). Of course, it is rather easy to access 
 the Windows partition from the F17 partition, which I
 have been doing with no noticeable problems: the File Explorer equivalent, 
 Dolphin (the KDE equivalent) will automount the Windows
 partition as a filesystem under /media, I only have to enter the password 
 for 'su'.

 I don't think it makes a difference, but for completeness I provide the 
 options with which I find it mounted:

 /dev/sda2 on /media/Windows7_OS type fuseblk (rw,nosuid,nodev,relatime,
 user_id=0,group_id=0,default_permissions,allow_other,blksize=4096).

 Anyway, the problem is this: the very same files, e.g. 
 /media/Windows7_OS/cygwin/home/Matthew
 Johnson/MrEd/mr.ed/lesson1/images/home-icon.jpg show up as 'modified' when 
 I type git status (in the mr.ed/ dir) using the F17 git client,
 but do not show up at all when I type git status under the Cygwin client. 
 This problem is not on all files, only a few, predominantly in
 two directories. 

 Under Windows (cygwin) git status shows nothing to commit, only untracked 
 files, which is what I expect; only under F17 do I get several modified 
 files -- and these have old dates (e.g. Nov 27).

 Yes, that is another

[git-users] Re: Why Same Files show up with different Statuses in Git?

2013-01-30 Thread Matthew Johnson 
Good guess, I had not been thinking about the different EOLs, but all the 
files that show up as modified only under Fedora are .ogg files: no EOLs at 
all. Even weirder, the textual files, whether HTML or JavaScript, do not 
have this problem. So it is hard to see how EOL inconcistency could explain 
why sound files are showing up as modified.

On Wednesday, January 30, 2013 11:30:28 AM UTC-8, Alex Lewis wrote:

 I think this question on stackoverflow might help... - 
 http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git

 Basically the problems stems to you using the same physical repo with two 
 different types of Git client, one built to use Windows EOL and the other 
 using Linux EOL. When you mix the two, I.e. work with a file in Linux when 
 it was created whilst on Windows I think you'll run into problems. I think 
 if you set up the Windows client correctly (or specifically use the 
 .gitattributes file for the repository) I *think* you'll be ok. 

 HTH

 On Wednesday, 30 January 2013 02:40:47 UTC, Matthew Johnson wrote:

 I hate to cross post, but I can no longer see my message to the same 
 effect at the Git mailing list, where I got no reply, so here we go:

 First, some background. I have one hard disk separated into two partitions: 
 one for the version of Windows 7 that shipped on this rather new 
 Thinkpad (Windows 7 Professional SP1), the other for Fedora 17 (which I 
 installed and keep up-to-date). Of course, it is rather easy to access 
 the Windows partition from the F17 partition, which I
 have been doing with no noticeable problems: the File Explorer equivalent, 
 Dolphin (the KDE equivalent) will automount the Windows
 partition as a filesystem under /media, I only have to enter the password 
 for 'su'.

 I don't think it makes a difference, but for completeness I provide the 
 options with which I find it mounted:

 /dev/sda2 on /media/Windows7_OS type fuseblk (rw,nosuid,nodev,relatime,
 user_id=0,group_id=0,default_permissions,allow_other,blksize=4096).

 Anyway, the problem is this: the very same files, e.g. 
 /media/Windows7_OS/cygwin/home/Matthew
 Johnson/MrEd/mr.ed/lesson1/images/home-icon.jpg show up as 'modified' when 
 I type git status (in the mr.ed/ dir) using the F17 git client,
 but do not show up at all when I type git status under the Cygwin client. 
 This problem is not on all files, only a few, predominantly in
 two directories. 

 Under Windows (cygwin) git status shows nothing to commit, only untracked 
 files, which is what I expect; only under F17 do I get several modified 
 files -- and these have old dates (e.g. Nov 27).

 Yes, that is another important note: I am running Cygwin on the Windows 
 partition.

 The versions of things under the F17 partition are:

   Linux 3.7.3-101.fc17.x86_64 x86_64
   System:  Fedora release 17 (Beefy Miracle)
   KDE:  4.9.5

 git --version
 git version 1.7.11.7

 Under Cygwin, the git version is 1.7.9.

 Finally, I did check the git configuration to make sure the same 
 user.name and user.email are set in both. And in both cases, I made mr.ed 
 the current directory before executing git status. Shouldn't that be 
 enough? Is there anything else that must match in the git config?



-- 
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/groups/opt_out.

[git-users] Re: Why Same Files show up with different Statuses in Git?

2013-01-30 Thread Matthew Johnson 
Please explain why I would need a third partition to do this. I am not 
aware of any restrictions in Git concerning what machine/partition the 
workspace and repository must live on, except that the remote is expected 
to really be remote, i.e., not on the local machine, accessible only over 
the net, whether via git:// scheme or some other. And why would files be 
changed when you jump back and forth? If both the workspace and 
repository are one and the same partition, why would it make any difference 
which filesystem it is mounted on or accessed from? The same .git files are 
being read, the same submitted files, etc.

BTW: I am trying to do both the things you mention: keep one work area I 
can use from either Windows or Linux and keep a remote repo I can get to 
from both (upstream). The latter is already achieved, it is the first that 
is giving me strange discrepancies concerning which files are modified.

Because of this discrepancy, though I continue to edit files running either 
Windows or Fedora, I do the revision control only while running Windows. 
But this is far from ideal, especially when it looks like I am so close to 
getting the ability to run Git correctly from either.

BTW: the remote repository is at Github. But since I am so underwhelmed by 
their GUI, I stick to command line Git whenever possible: the Git 
documentation is good enough that I have a much better idea what is really 
going on when I execute a Git command on the command line, despite the 
problem I am having with these dubious 'modified' reports.

On Wednesday, January 30, 2013 9:24:26 AM UTC-8, John Fisher wrote:

 Matthew, I defer to actual Git experts... but heres some sysadmin ideas:

 Are you trying to keep one work area you can use for Windows and for Linux? 
 Or are you trying to keep a remote repos
 which you can get to from both?

 If you create a third partition and put your Git workarea and repository 
 there, then you could mount it from both
 Windows and Linux. But files are going be changed when you jump back and 
 forth. You could also switch to running Linux,
 and put up a VM of Windows ( or vice versa) and have both running at once, 
 keeping your remote repos on Linux and having
 two work areas. Or, you could get that old Pentium4/ Pentium/ AMD dog out of 
 the closet or for $25 at the thrift store,
 and set up a Linux server with a remote repository. Or you could host your 
 project at github.

 John



 On Tuesday, January 29, 2013 6:40:47 PM UTC-8, Matthew Johnson wrote:



 First, some background. I have one hard disk separated into two partitions: 
 one for the version of Windows 7 that shipped on this rather new 
 Thinkpad (Windows 7 Professional SP1), the other for Fedora 17 (which I 
 installed and keep up-to-date). Of course, it is rather easy to access 
 the Windows partition from the F17 partition, which I
 have been doing with no noticeable problems: 



-- 
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/groups/opt_out.

Re: [git-users] Why Same Files show up with different Statuses in Git?

2013-01-30 Thread Matthew Johnson 
What differences does it display? It lists about a hundred .ogg files (like 
the one I included) as 'modified'. I did not want to burden the group with 
the whole list, so I mentioned only one .ogg file. But here are the first 
few lines, which include ogg, jpb, and png files:

[mejohnsn@localhostThinkpad mr.ed]$ git status
# On branch master
# Changes not staged for commit:
#   (use git add file... to update what will be committed)
#   (use git checkout -- file... to discard changes in working 
directory)
#
#   modified:   fix_ogg.py
#   modified:   lesson1/images/home-icon.jpg
#   modified:   lesson1/images/home-icon.png
#   modified:   lesson1/images/left-arrow.png
#   modified:   lesson1/images/right-arrow.png
#   modified:   lesson2/images/home-icon.jpg
#   modified:   lesson3/images/home-icon.jpg
#   modified:   lesson3/lesson_a/images/home-icon.jpg
#   modified:   lesson3/lesson_a/sounds/1.ogg
#   modified:   lesson3/lesson_a/sounds/10.ogg
...

It even includes one Python file I forgot to mention since I have no 
intention of checking it into the repository;)

None of these show up as modified when I type the same git status in a 
Cygwin command line.

On Wednesday, January 30, 2013 8:21:37 AM UTC-8, Dale Worley wrote:

  From: Matthew Johnson mejo...@gmail.com javascript: 
  
  Under Windows (cygwin) git status shows nothing to commit, only 
 untracked 
  files, which is what I expect; only under F17 do I get several modified 
  files -- and these have old dates (e.g. Nov 27). 

 My guess is that it has something to do with line-endings or some 
 subtlety about how file modification times are handled. 

 Under F17, when you do a git diff, what differences does it display? 

 Dale 


-- 
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/groups/opt_out.