Newbie question

Newbie question

[kinley]

Hi,
I am new to question. Please help me with this.
I copied an already existing project from a remote server using scp to my
local directory.
The contents of this directory are
   branches
   config
   description
   HEAD
   hooks
   info
   objects
   ref

I checked all the directories and sub-directories but could not find a
single source code file (in C language).
All I can see at the leaf level appear to be MD5 hash code.

Is there any command to retrieve the source files ? 
As per manual, only then I guess I can add them to git.

Any help would be appreciated.
Thanks
-- 
View this message in context: http://git.661346.n2.nabble.com/Newbie-question-tp5548737p5548737.html
Sent from the git mailing list archive at Nabble.com.

Re: Newbie question

[Andrew Keller]

On Sep 19, 2010, at 7:51 PM, kinley wrote:

> Hi,
> I am new to question. Please help me with this.
> I copied an already existing project from a remote server using scp to my
> local directory.
> The contents of this directory are
>   branches
>   config
>   description
>   HEAD
>   hooks
>   info
>   objects
>   ref

This directory listing is what you would expect if you were looking at the repository itself.  To access your files in the repository, you want to create a non-bare (normal) clone.

git clone path-to-git-repo

On a side note, git can clone over ssh, so you don't need to use scp to copy a project over the network.  If your intent is to create a clone of a remote project on your computer, then cloning over ssh generally takes fewer commands than doing the copy manually first.

~ Andrew Keller

Re: Newbie question

[kinley]

Thanks for your help.

Actually now I tried doing this

git clone ssh://user@host/~/GPUProject/Histogram

but getting

bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

I tried several ways of specifying the path of the URL assuming that this
could be a path issue but every time it gives the same error.

Thanks once again.
-- 
View this message in context: http://git.661346.n2.nabble.com/Newbie-question-tp5548737p5548842.html
Sent from the git mailing list archive at Nabble.com.

Re: Newbie question

[Imran M Yousuf]

Try:
git clone user@host:/home/user/GPUProject/Histogram/.git/

I added .git assuming that, that is the folder to which you gave the
ls output in your first email, the path should be upto that folder.

On Mon, Sep 20, 2010 at 6:50 AM, kinley <arjuncode@gmail.com> wrote:
>
> Thanks for your help.
>
> Actually now I tried doing this
>
> git clone ssh://user@host/~/GPUProject/Histogram
>
> but getting
>
> bash: git-upload-pack: command not found
> fatal: The remote end hung up unexpectedly
>
> I tried several ways of specifying the path of the URL assuming that this
> could be a path issue but every time it gives the same error.
>
> Thanks once again.
> --
> View this message in context: http://git.661346.n2.nabble.com/Newbie-question-tp5548737p5548842.html
> Sent from the git mailing list archive at Nabble.com.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Imran M Yousuf
Entrepreneur & CEO
Smart IT Engineering Ltd.
Dhaka, Bangladesh
Twitter: @imyousuf - http://twitter.com/imyousuf
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557

Re: Newbie question

[Kevin Ballard]

It sounds like git-upload-pack is not in the PATH of your non-interactive shell. Assuming git is installed on the remote host, you should ssh in to it and figure out where git is installed (run `git --exec-path`), then run your command like so

git clone -u /path/to/libexec/git-core/git-upload-pack ssh://user@host/~/GPUProject/Histogram

In my case that path is /usr/local/libexec/git-core/git-upload-pack.

-Kevin Ballard

On Sep 19, 2010, at 5:50 PM, kinley wrote:

> 
> Thanks for your help.
> 
> Actually now I tried doing this
> 
> git clone ssh://user@host/~/GPUProject/Histogram
> 
> but getting
> 
> bash: git-upload-pack: command not found
> fatal: The remote end hung up unexpectedly
> 
> I tried several ways of specifying the path of the URL assuming that this
> could be a path issue but every time it gives the same error.
> 
> Thanks once again.
> -- 
> View this message in context: http://git.661346.n2.nabble.com/Newbie-question-tp5548737p5548842.html
> Sent from the git mailing list archive at Nabble.com.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Newbie question

[kinley]

Thanks Kevin and All.

Specifying the path of git-upload-pack helped.

Thanks once again.
-- 
View this message in context: http://git.661346.n2.nabble.com/Newbie-question-tp5548737p5551972.html
Sent from the git mailing list archive at Nabble.com.

Re: Newbie question

[Jakub Narebski]

kinley <arjuncode@gmail.com> writes:

> I am new to question. Please help me with this.
> I copied an already existing project from a remote server using scp to my
> local directory.

In the future use "git clone <scp-location>" instead of 'scp'.

> The contents of this directory are
>    branches
>    config
>    description
>    HEAD
>    hooks
>    info
>    objects
>    ref
> 
> I checked all the directories and sub-directories but could not find a
> single source code file (in C language).
> All I can see at the leaf level appear to be MD5 hash code.
> 
> Is there any command to retrieve the source files ? 
> As per manual, only then I guess I can add them to git.

You have the repository itself (the object database containg all
version info plus other info).  Put those files and directories into
<project>/.git subdirectory, and use "git checkout" from within it.
You should have checked out files in <project>/ directory.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Newbie question

[Alex Riesen]

On Mon, Sep 20, 2010 at 01:51, kinley <arjuncode@gmail.com> wrote:
>
> Hi,
> I am new to question. Please help me with this.
> I copied an already existing project from a remote server using scp to my
> local directory.
> The contents of this directory are
>   branches
>   config
>   description
>   HEAD
>   hooks
>   info
>   objects
>   ref
>
> I checked all the directories and sub-directories but could not find a
> single source code file (in C language).
> All I can see at the leaf level appear to be MD5 hash code.

It is SHA-1

> Is there any command to retrieve the source files ?

try this:

  git clone . ../Histogram

But others are right, and you should have used git clone, instead of scp.

Re: Newbie question

[George Spelvin]

Jakub Narebski wrote:
> You have the repository itself (the object database containg all
> version info plus other info).  Put those files and directories into
> <project>/.git subdirectory, and use "git checkout" from within it.
> You should have checked out files in <project>/ directory.

What he said.  Cloning it in the first place is the easier approach, but
what happened is that you got a copy of a "bare" repostitory (without
checked-out files, suitable only for remote access), which is typically
in a directory named "project.git".

What you want is a normal tree, where all the git files are in "project/.git"

This is pretty easy to do:

mkdir project
mv project.git project/.git
cd project
git config core.bare true
git checkout

That does 3 things:
- Set up the directory structure correctly,
- unset the core.bare flag, which disables certain commands that
  make no sense on a bare repository, and
- Check out a working copy

Re: Newbie question

[Thomas Hochstein]

George Spelvin wrote:

> git config core.bare true
[...]
> - unset the core.bare flag, which disables certain commands that
>   make no sense on a bare repository, and

Shouldn't that be
| git config core.bare false
then?

Regards,
-thh

newbie question

[Alex K]

Hello,

I would think the following simple pattern would be possible:

Create two branches A and B. Switch to A, modify some files, do not
commit to A, switch to B. Now B should not show any of the changes
performed to A? However a git status while on B does show that the
files on A have been modified. Is there something I am missing?

Thank you,

Alex

Re: newbie question

[dloewenherz]

Until you commit the files, the changes will follow you to whatever branch
you go to. If you don't want to commit, but still want to switch to B and
not see the changes in A, I would recommend using `git stash`.

e.g.

git checkout A
...edit...
git stash save changes
git checkout B
git status

You'll see that your tree is clean. To get your changes back to A, just run

git checkout A
git stash pop changes

Best,
Dan

On 03/07/09 11:39 -0700, Alex K wrote:
>Hello,
>
>I would think the following simple pattern would be possible:
>
>Create two branches A and B. Switch to A, modify some files, do not
>commit to A, switch to B. Now B should not show any of the changes
>performed to A? However a git status while on B does show that the
>files on A have been modified. Is there something I am missing?
>
>Thank you,
>
>Alex
>--
>To unsubscribe from this list: send the line "unsubscribe git" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: newbie question

[Junio C Hamano]

Alex K <spaceoutlet@gmail.com> writes:

> I would think the following simple pattern would be possible:
>
> Create two branches A and B. Switch to A, modify some files, do not
> commit to A, switch to B. Now B should not show any of the changes
> performed to A? However a git status while on B does show that the
> files on A have been modified. Is there something I am missing?

Yes, you are missing the basic concept of how git works and how to work
with git.

"Switch to A, modify some files, do not commit to A".

The modification does _not_ belong to A at this point yet.

Then you "switch to B."  At this point, you switched branches and carried
your modification along with you.  B does _not_ show any of the changes
performed to A, as you never committed to A yet.

What you see is the changes you performed to your _work tree_ (and your
_index_, if you are using it).

And this is a deliberately designed behaviour.  When you start hacking on
something, you often do not know many things a-priori, including

 - if the change is small and simple enough that you can finish it in a
   single sitting;

 - what is the oldest branch that the change is necessary

The former means that you may start working on a cool feature while you
have a checkout of your 'master' branch, but then you realize that the
necessary changes are much more involved than what you originally thought,
and you are better off building that feature on a new side branch while
you have to work on completing it, and in the meantime, you would want to
keep your 'master' branch clean, so you do _not_ want to commit any of
this work-in-progress there.  So the behaviour allows you to do this:

    $ hack hack hack ;# yeah, looking good
    $ hack hack      ;# oops, this is a bit more complex than I thought
    $ git checkout -b cool-feature
    $ hack more ;# good point to snapshot even though it is not complete
    $ git commit 
    $ hack even more ;# oops, boss tells me to fix something else right away
    $ git commit -a -m 'WIP' ;# I'll come back to it later
    $ git checkout master
    $ work test work test ;# handle boss's wish
    $ git commit -a -m 'Urgent fix'
    $ git push origin master ;# emergency handled well
    $ git checkout cool-feature
    $ hadk hack ;# continue working
    ...

Notice the third step where you switch to the branch cool-feature (newly
created).  You are taking your changes up to that point in your work tree
along with you when starting to work in that branch, and it is a good
thing.

The latter means that you may start fixing a bug while you have a checkout
of your 'master' branch, but then realize that the bug has existed from a
long time ago, and the same fix needs to go to your maintenance branch.
Again, the behaviour allows you to do this:

    $ fix test fix test ;# Ok, I think it is good.
    $ git blame HEAD -- broken.rb ;# where did this bug came from anyway?
    ... find the commit that introduced the bug from the above blame ...
    $ git branch --with $commit ;# on which branches is the bad commit in?
    ... realize that the maintenance branch also has the same bug ...
    $ git checkout maint
    $ test it again
    $ git commit ;# commit fix to the oldest applicable branch
    $ git checkout master
    $ git merge maint ;# and propagate it upwards

Again, notice that the "checkout" to switch to the 'maint' branch takes
the changes in your work tree along with you, and that is what allows you
to fix the bug in the oldest applicable branch.

It also happens that you notice an unrelated breakage while working on
something on a topic branch 'feature', and realize that the breakage is
grave enough that you should fix it on 'master' branch.  You would do
this:

    $ git checkout feature ;# let's do a cool feature
    $ edit feature.rb ;# yeah, looking good
    $ edit broken.rb ;# this is unrelated
    $ git checkout master
    $ git add broken.rb ;# only add the fix to the index
    $ git commit -m 'Fix' ;# never use "commit -a" when you do this
    $ git checkout feature ;# continue working

Again, because the changes to broken.rb (together with the changes to
feature.rb) are carried across branch switching, you can fix the buggy  
code on your master branch, and come back (again, taking the changes to
feature.rb with you) to continue.

Re: newbie question

[Sitaram Chamarty]

On 2009-07-03 19:22:49, Junio C Hamano <gitster@pobox.com> wrote:

>     $ git branch --with $commit ;# on which branches is the bad commit in?

--with?  Did --contains get an alternative form?

Re: newbie question

[Michael J Gruber]

Sitaram Chamarty venit, vidit, dixit 04.07.2009 02:29:
> On 2009-07-03 19:22:49, Junio C Hamano <gitster@pobox.com> wrote:
> 
>>     $ git branch --with $commit ;# on which branches is the bad commit in?
> 
> --with?  Did --contains get an alternative form?
> 

No, it always had one :)

git log -S'"with"' --pretty=oneline
694a577519a762d12b8a53e76b6f1dd3ccf25e7d git-branch --contains=commit

Cheers,
Michael

newbie question

[Li Yang-r58472]

I just starting to use git recently.  I have setup a public repository, and pushed cloned open source repository to it.  As most documents suggested, I need to run a repack on the public repository.  Normally git-repack is run in the source directory(the parent directory of .git).  Considering the public repository, there is no source directory and the *.git is the uppest level directory.  Where am I supposed to run the git-repack command?

Re: newbie question

[Matthias Kestenholz]

Hello,

* Li Yang-r58472 (LeoLi@freescale.com) wrote:
> I just starting to use git recently.  I have setup a public repository,
> and pushed cloned open source repository to it.  As most documents 
> suggested, I need to run a repack on the public repository.  Normally 
> git-repack is run in the source directory(the parent directory of .git).  
> Considering the public repository, there is no source directory and the
> *.git is the uppest level directory.  Where am I supposed to run the
> git-repack command?

Do it like that:

$ ls
project.git
$ GIT_DIR=project.git git-repack -a -d