[git-users] How to create a repo

2014-06-04 Thread Eric Fowler
This should be screamingly easy, in fact, I know I have done this before - 
but I forget how. 

I do remember that I had a hard time with it before.  :-(

I have created a file on my C:\ drive. Let us call it 
c:\mydir\helloworld.cmd . 

I have a Z: drive mapped with lots of drive space and write privs. This 
drive is accessible to the millions of programmer-slaves under my command. 

I wish to use z: as a repository for all my code, and for all my 
programmer-slaves code. 

I wish to add my helloworld.cmd file to that repository. 

How do I do this? 

I know how to use 'git init' to create a repo on C:, and how to use 'git 
add', 'git commit', and 'git push'. But I don't know how to tell 'git push' 
to use Z: as a target, and I don't know what I have to do to prepare z:\ to 
receive the 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.


Re: [git-users] How to create a repo

2014-06-04 Thread John McKown
This is somewhat confusing to me as to what you really want. Do you want a
bare repository on your Z: drive? This means you  your subordinates
would need to git clone to create their own copy (working directory). Or
do you actually want to have the .git subdirectory for your (and other
users') c:\mydir to reside on the Z: drive instead of being a subdirectory
(folder to Windows types) in c:\mydir? The first case is simply git init
--bare --shared z:\repodir to create a bare repository which you and
others can then git clone z:\repodir followed by git push to update.
This is what I am used to doing. If the later, look at git init
--separate-git-dir z:\repodir. I really don't know if this latter will
work if multiple people need up update it (which is what I think a git
add or git commit will do). Perhaps one of the true experts will comment
on having a shared git index setup of this sort. Personally, I go with
be afraid! Be very, very afraid! in this latter case. I don't think git
is designed to allow sharing of an index folder on a CIFS (Windows share)
shared directory. But I've been wrong in the past. Well, it's 02:25 and I
need to try to get back to sleep, if I just could.


On Wed, Jun 4, 2014 at 1:49 AM, Eric Fowler eric.fow...@gmail.com wrote:

 This should be screamingly easy, in fact, I know I have done this before -
 but I forget how.

 I do remember that I had a hard time with it before.  :-(

 I have created a file on my C:\ drive. Let us call it
 c:\mydir\helloworld.cmd .

 I have a Z: drive mapped with lots of drive space and write privs. This
 drive is accessible to the millions of programmer-slaves under my command.

 I wish to use z: as a repository for all my code, and for all my
 programmer-slaves code.

 I wish to add my helloworld.cmd file to that repository.

 How do I do this?

 I know how to use 'git init' to create a repo on C:, and how to use 'git
 add', 'git commit', and 'git push'. But I don't know how to tell 'git push'
 to use Z: as a target, and I don't know what I have to do to prepare z:\ to
 receive the 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.




-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! 
John McKown

-- 
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] How to create a repo

2014-06-04 Thread Gergely Polonkai
You must first create an empty repository on Z:, add it as a remote in
C:\mydir, then issue the git push. Basically as follows, although I
don’t know how Windows git handles backslashes in paths, so maybe you
will have to replace it wich slashes:

C:\mydir Z:
Z:\ mkdir projectname
Z:\ cd projectname
Z:\projectname git init --bare
Initialized empty Git repository in Z:\projectname\
Z:\projectname C:
C:\mydir git remote add origin Z:\projectname
C:\mydir git push origin master

On 4 June 2014 08:49, Eric Fowler eric.fow...@gmail.com wrote:
 This should be screamingly easy, in fact, I know I have done this before -
 but I forget how.

 I do remember that I had a hard time with it before.  :-(

 I have created a file on my C:\ drive. Let us call it
 c:\mydir\helloworld.cmd .

 I have a Z: drive mapped with lots of drive space and write privs. This
 drive is accessible to the millions of programmer-slaves under my command.

 I wish to use z: as a repository for all my code, and for all my
 programmer-slaves code.

 I wish to add my helloworld.cmd file to that repository.

 How do I do this?

 I know how to use 'git init' to create a repo on C:, and how to use 'git
 add', 'git commit', and 'git push'. But I don't know how to tell 'git push'
 to use Z: as a target, and I don't know what I have to do to prepare z:\ to
 receive the 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.

-- 
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] How to create a repo

2014-06-04 Thread Eric Fowler
This worked. 

Thanks to Mr. Polonkai. 

Eric

On Wednesday, June 4, 2014 12:23:32 AM UTC-7, Gergely Polonkai wrote:

 You must first create an empty repository on Z:, add it as a remote in 
 C:\mydir, then issue the git push. Basically as follows, although I 
 don’t know how Windows git handles backslashes in paths, so maybe you 
 will have to replace it wich slashes: 

 C:\mydir Z: 
 Z:\ mkdir projectname 
 Z:\ cd projectname 
 Z:\projectname git init --bare 
 Initialized empty Git repository in Z:\projectname\ 
 Z:\projectname C: 
 C:\mydir git remote add origin Z:\projectname 
 C:\mydir git push origin master 

 On 4 June 2014 08:49, Eric Fowler eric@gmail.com javascript: 
 wrote: 
  This should be screamingly easy, in fact, I know I have done this before 
 - 
  but I forget how. 
  
  I do remember that I had a hard time with it before.  :-( 
  
  I have created a file on my C:\ drive. Let us call it 
  c:\mydir\helloworld.cmd . 
  
  I have a Z: drive mapped with lots of drive space and write privs. This 
  drive is accessible to the millions of programmer-slaves under my 
 command. 
  
  I wish to use z: as a repository for all my code, and for all my 
  programmer-slaves code. 
  
  I wish to add my helloworld.cmd file to that repository. 
  
  How do I do this? 
  
  I know how to use 'git init' to create a repo on C:, and how to use 'git 
  add', 'git commit', and 'git push'. But I don't know how to tell 'git 
 push' 
  to use Z: as a target, and I don't know what I have to do to prepare z:\ 
 to 
  receive the 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+...@googlegroups.com javascript:. 
  For more options, visit https://groups.google.com/d/optout. 


-- 
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 reset with staged changes

2014-06-04 Thread Pierre-François CLEMENT

 Beware, though.  I don't have my Git reference to hand, but I've noted
 that if the file is in the index, it is tracked [...]


Really? Sounds a bit strange. I feel like tracked files are committed
files, and that staged files are about-to-be-tracked files so in a sort
of a transient state. But in the mean time it also makes sense cuz' we
don't want commands that act on untracked files to act on staged untracked
files. But then I feel the reverse should also be true, and I don't want
commands that *specifically don't act on untracked files* (like git-reset)
to act on staged untracked files...

So I'm not sure what to think here. I've searched through the git-glossary,
git-add, git-update-index, git-status etc man pages and couldn't find any
hints on wether staged files are tracked files or not. Can anyone shed some
light on this?

-- 
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 reset with staged changes

2014-06-04 Thread Paul Smith
On Wed, 2014-06-04 at 11:23 +0200, Pierre-François CLEMENT wrote:
 Beware, though.  I don't have my Git reference to hand, but
 I've noted that if the file is in the index, it is
 tracked [...]

 Really? Sounds a bit strange. I feel like tracked files are
 committed files, and that staged files are about-to-be-tracked files

I'm no expert on Git but I think you're looking at it wrong.  What's
below is my understanding:

A tracked file is a file that Git knows about.  An untracked file is a
file Git doesn't know about.  More concretely, any file that has ever
been git add'd is tracked.  Files that have never been git add'd are
not tracked.  That means files that are committed and unmodified, files
that are staged (whether they've previously been committed or not), and
files that have been committed or staged and are now modified are all
tracked files.

Given these states a file can be in:

 1. committed
 2. staged change to a previous committed file
 3. modified version of previously committed file
 4. staged new file that's never been committed
 5. untracked file

The first four are tracked.  I think git reset --hard currently does
the right thing  for the first 3--it's defined to throw away
modifications (#3) and people WANT it to do that much of the time, so
there's no way that behavior could be changed IMO.  Possibly it could
save the modifications to backup files, or require a force option and
without it suggest you stash modified files, or whatever.

You may have an argument about #4.  I personally think it would be
reasonable to have git reset --hard turn staged files that are new
back into untracked files, rather than just deleting them.


-- 
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 reset with staged changes

2014-06-04 Thread Dale R. Worley
 From: Pierre-François CLEMENT lik...@gmail.com
 
 Really? Sounds a bit strange. I feel like tracked files are committed
 files, and that staged files are about-to-be-tracked files so in a sort
 of a transient state.

Yeah, but what one *feels* is the definition of the word is not
relevant.  To work consistently, Git has to have a definition of
tracked and stick with it.  (Though one can reasonably argue that
Git would work better with a different definition, one has to think
long and hard about changing such a central design decision.)

 So I'm not sure what to think here. I've searched through the git-glossary,
 git-add, git-update-index, git-status etc man pages and couldn't find any
 hints on wether staged files are tracked files or not. Can anyone shed some
 light on this?

Unfortunately, you're running into the problem that Git isn't at all
well documented.  I can't find the source right now, but I'm certain
that the definition I quoted was from the O'Reilly book.  But I have
no idea where that author got it from; perhaps he found it by
experimentation.

The online book is particularly treacherous:
http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository

Remember that each file in your working directory can be in one of
two states: tracked or untracked. Tracked files are files that
were in the last snapshot; they can be unmodified, modified, or
staged. Untracked files are everything else — any files in your
working directory that were not in your last snapshot and are not
in your staging area.

If you read carefully, you'll note that it is self-contradictory:  His
definition of tracked excludes staged-but-not-in-the-head-commit files
but his definition of untracked also excludes those files.

 From: Paul Smith p...@mad-scientist.net
 
 A tracked file is a file that Git knows about.  An untracked file is a
 file Git doesn't know about.  More concretely, any file that has ever
 been git add'd is tracked.  Files that have never been git add'd are
 not tracked.

That's not true either.  If in one commit a file was added, and in the
next commit, it was deleted, then *now* it is untracked (even though
it was once added).

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/d/optout.


Re: [git-users] Re: git reset with staged changes

2014-06-04 Thread Paul Smith
On Wed, 2014-06-04 at 10:28 -0400, Dale R. Worley wrote:
  From: Paul Smith p...@mad-scientist.net
  
  A tracked file is a file that Git knows about.  An untracked file is a
  file Git doesn't know about.  More concretely, any file that has ever
  been git add'd is tracked.  Files that have never been git add'd are
  not tracked.
 
 That's not true either.  If in one commit a file was added, and in the
 next commit, it was deleted, then *now* it is untracked (even though
 it was once added).

There are a million special case situations and it's too exhausting for
both the author and the reader to be sure to cover all of them every
time, which is why you perceive ambiguities in the documentation.

Also, this can be considered a matter of definition.  Another way to
look at it is that the file in that directory now has never been git
add'd because it's a different file, as the one before was deleted.  If
you delete a file foo from your directory then create a new file
foo, is it the same file?  Or a different file?  If a cat named Felix
is sitting in a box then you take it out and put in another cat also
named Felix, is the cat in the box the same cat or a different cat?
What if the two cats are clones?

And, how can you use Git to answer these questions?

:-).

Anyway, the only trivially correct answer is that if you run git
status and it reports the file is untracked, then it's untracked.  If
it reports the file is in any other state, then it's tracked.

-- 
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] Setting log message with git merge --squash... ?!?!

2014-06-04 Thread Paul Smith
So, it appears to be impossible to set or change the log message in any
way when doing git merge --squash.  I've tried all of these, at least:

  * --log
  * --no-log
  * --log=0
  * -m foo

No matter what options I provide the squash merge commit message always
appears as the standard computed message, completely unchanged.

The only solution I've found is go whack the .git/SQUASH_MSG file
directly after the merge command completes!!

Is this really right?  It seems ridiculous to me that I cannot control
that message from the command line.  Why is the --squash version of the
merge command so anemic in this respect compared to a normal merge
command?

I'm using Git 1.8.5.3; maybe this is improved in a newer version?

-- 
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] Looking for a GIT Mentor in S. Central PA

2014-06-04 Thread msatvr via Git for human beings
I am a new GIT user but I seem to be spending a lot of time trying to 
figure out what I am doing wrong.  Would love a mentor I could call on or 
possibly spend a little time with to help me over the hump.  If there is a 
better site for finding users close to me please direct me.

Thanks

-- 
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.