Re: [git-users] How do we completely backup a git repository ?

[tombert]

>
>
>   git init --bare foo.git 
>   cd foo.git 
>   git fetch $source_repo_url 'refs/*:refs/*' 
>
>
>
Just a note to make this complete - this works as long as you do not use 
annexes and LFS.

-- 
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] git svn fetch branch mismatch

[Perry Ismangil]

Hi all,

Following https://www.atlassian.com/git/tutorials/migrating-synchronize, I 
was able to largely successful migrating 
https://svn.pjsip.org/repos/pjproject/ to 
https://git.pjsip.org/gitpub/pjproject.git

Synchronizing the trunk with master works.

However I am now having problems fetching svn branch checkins, such as svn 
r5256 in uwp branch to appear in my local git sync repo.

git svn fetch when done in both master or uwp branch reports nothing 
change, while git log only shows latest commits corresponding to svn r5255.

Where do I start to debug this issue - which mapping/logs should I check?

Thank you.

Best regards,


-- 
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] stash for remote?

[Konstantin Khomoutov]

On Thu, 10 Mar 2016 23:27:01 +0100
Pablo Rodríguez  wrote:

[...]
> > If we suppose we're talking about the branch "master", and the
> > remote server is known as "origin", then you'd do something like
> > this:
> > 
> > First do
> > 
> > git fetch origin
> > 
> > to have origin/master updated to the state of "master" at "origin".
> > 
> > Then either do
> > 
> > git branch temp master
> 
> Probably I prefer creating a branch. But isn’t it better to create the
> branch before fetching contents from the remote server?

It's irrelevant: the command above creates a local branch named "temp"
which points to the same commit a local branch "master" currently
points at.  That is, at this point, the data from the remote server is
not involved at all.  The reason for the execution of this command is
to have "something" -- a branch in this case -- to point to whatever
"master" currently points at.  This is needed because we're about to
"retarget" the branch "master" with the next few commands.

> > Next, reset your local "master" to "origin/master":
> > 
> > git checkout master
> > git reset --hard origin/master

This `git reset` command accesses the so-called "remote-tracking branch"
named "origin/master" which does indeed track the state of the "master"
branch as found in the remote repository known as "origin".  To have it
in an up-to-date state, running `git fetch` is needed.  So, fetching
the contents from the remote repository is needed before running this
command.  Contrary to this, operations which only touch local branches
do not care about the state of the remote repository.

> > You might also consider rebasing.  If your original problem was to
> > deal with the case where you have a series of local commits on a
> > branch you'd like to push "upstream" but the upstream version of
> > your branch got updated so your commits can't be used to
> > fast-forward it (don't push cleanly) then you might use `git
> > rebase`:
[...]
> Fine, but too complex for me. And origin hasn’t been updated.

That's a bit surprising to read because, as I understood it, your
situation was exactly the "origin" having been updated compared to your
local case. ;-)

I'd honestly recommend you to read a book on Git: it helps to have a
clear vision of what a tool can do for you, so, when confronting with a
problem you have a good overview of which methods can be used to deal
with it.  Please refer to [1] (other good books exist as well).

1. http://git-scm.com/book

-- 
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] dropped stash without applying

[Konstantin Khomoutov]

On Thu, 10 Mar 2016 21:56:07 +0100
Pablo Rodríguez  wrote:

[...]
> As far as I know, all my repos are normal. I don’t know how to get
> non-bare repositories (no idea of what these might be).
[...]

A bare repository is a repository with no work tree -- which contains
the files currently checked out -- and the index (the staging area).

A normal (also: "regular", "non-bare") repository consists of a work
tree and a subdirectory named ".git" in it which contains the local
repository's data.  A bare repository has no work tree and no index.
That is, the directory with a bare repository contains the repository's
data right at the top level.  (Because of this, it's customary to
attach the suffix ".git" to the names of directories of bare
repositories.)

Bare repositories are hardly usable for performing "regular" tasks of
recording commits in them and are mostly used for "server-side"
repositories which everyone pushes their stuff into and fetches others'
stuff from.  To give an example, all repos in public Git hostings (such
as Bitbucket, Github etc) are bare.

A number of "casual" tasks can still be performed in bare repositories.
Say, you can enumerate/create/delete/reset branches in them, inspect
their history, manipulate configuration etc.

With advanced commands, it's possible to fetch files of particular
commits from such repos, which is commonly used for, say, website
deployments.

-- 
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: Storing file on a server rather than on the git folder

[tombert]

SourceTree does support LFS.
See "Repository->Git LFS" - although I never used it.

On Friday, 12 February 2016 12:18:09 UTC+1, Théo G wrote:
>
> Hello everyone, 
> I would like to know if it is possible to store file elsewhere that in the 
> git folder. 
> Let me explain myself: 
> We use Git a lot and therefore the folder just get bigger and bigger, 
> which slowed everything when we need to make a test or something else and 
> of course we need to keeptrack of every single file, so no cleaning 
> possible! 
> I've seen solution about how it is possible to manage large binary files 
> in Git (which is my problem), like git LFS, git annex, git bigfiles, 
> git-fat, git-media, etc... 
> The fact is I make my research and none of these solutions seem to be 
> perfectly adapted to our development environment. We use Git on Windows and 
> SourceTree as a Visual interface for Git. People here are afraid of command 
> line and I cannot make anything to change the environment. 
> My question is then: 
> Is it possible to store file not on the hard drive but on a local server 
> (like G://), maybe thanks to Git hook? 
> I hope I've been clear and thank you for your response of any kind, tips 
> and questions are welcome!
>

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