from:"Konstantin Khomoutov"

On Tue, 12 May 2015 00:40:13 -0700 (PDT)
Matthias Lantsch alasar.gogle.su...@gmail.com wrote:

 I usually always try to solve problems myself, but I really have
 gotten onto my limits with this.
 Situation:
 I am trying to create a php glue script between apache and the git
 http backend in order to allow myself to hook into all git processes
 via my php framework
[...]
 To make sure that the problem lies not with the server setup, I have 
 executed tests on 2 different linux machines as well as a windows
 machine. I was testing with a bare repository, which I added a single
 file to over local push (file://).
 GIt update-server-info was executed as well.
 But I always get the message:
 warning: You appear to have cloned an empty repository.
 Checking connectivity... done.
 And in my apache error log:
 fatal: 'test.git/info/refs': aliased\n
[...]

I reckon this might be the root of your problem.
Can you start with plain apache setup which works, and then transition
to your solution?

To be more clear, the basic idea of setting up Apache to be a front-end
to Git is somehow make sure that some common prefix on your designated
virtual host (or the default host, if applies) is defined to be a
script alias to the git-http-backend binary.  That is, something like:

  VirtualHost *:80
  ServerName  git.domain.local
  ServerAlias git
  
  DocumentRoot /srv/git
  
  ScriptAlias / /usr/lib/git-core/git-http-backend/
  
  # Access control directives etc...
  # Maybe also SetEnv GIT_PROJECT_ROOT /srv/git
  
  /VirtualHost

Once you have this working, replace the real git-http-backend with
your custom wrapper and have it done.

The git-http-backend manual page contains extensive examples, including
a way to make Apache serve certain static files directly (using
sendfile(2) on Linux and whatnot) rather than through the backend.

To recap, I'd work piecemeal: first get Git http backend working along
with your front-end and only then plug your PHP framework in place of
the backend, wrapping it.

-- 
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: Trouble with the git-http-backend; Documentation unprecise

On Tue, 12 May 2015 00:43:14 -0700 (PDT)
Matthias Lantsch alasar.gogle.su...@gmail.com wrote:

 I'm sorry I forgot about the most important part:
 setting the pth variable for the PATH_INFO
 $pth = explode(GIT_DOCUMENT_ROOT, isset($_SERVER
 ['REDIRECT_URL']) ? $_SERVER['REDIRECT_URL'] : '', 2);
 $pth = array_pop($pth);

One problem with the way you're communicating your difficulties with us
is that you imply everyone is fluent in PHP, which is just wrong ;-)

-- 
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] Help with git reset, please.

On Tue, 12 May 2015 20:34:01 -0700
Michael keybou...@gmail.com wrote:

[...]
 I'm just not understanding the git reset -- it seems to not just
 change the active branch, and possibly the working tree/cached for
 commit, but also alters where branch label point.
 
 That seems to be non-documented, and ... confusing.

Well, `git reset` is completely documented in its manual page
(try running `git help reset`).  The problem with this command is that
it gathers several modes of operation under the same name.

The general distinction is this:

* Two ways to call `git reset` make it to do a job essentially reverse
  to that of `git add`.  In this mode, `git reset` operates on the index
  only.

  These two ways to call `git reset` are:

git reset foo.js

  to unstage the changes made to foo.js and added to the index by
  calling `git add foo.js`.  In more strict terms, this command sets
  the index entry for the file foo.js to the contents it has at the
  HEAD revision.  You can specify a revision other than HEAD, if you
  want.  You can specify several files as well.

git reset --patch foo.js

  Runs you through an interactive hunk-by-hunk unstaging which is just
  like `git add --patch foo.js` but it removes the hunks from the index
  rather than adding them.  This command can be run with no files
  specified and then it works on the whole index.

* Anothe three ways to call `git reset` affect the currently checked out
  branch and possibly also the index and the work tree -- that's why
  there are three of them.

  These modes are selected by a special command line option: --soft,
  --hard or --mixed, with the latter being the default.

  The --soft option only repositions the branch's tip, the --mixed
  option performs what the --soft does and also resets the index to
  match the new tip.  --hard does everything --mixed does and also
  resets the work tree to match the new content of the index.

All this is documented in the manual page but the manual is, well,
a manual -- it's for strictly documenting, not for explaining from a
general standpoint -- that's what books and tutorials are for.

Hence I recommend you [1] and [2] to grasp the concepts in a non-manual
way.

1. http://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
2. http://threetrees.herokuapp.com/

-- 
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] Use git on microsoft words documents

On Thu, 14 May 2015 05:44:05 -0700 (PDT)
Massoud Yeganeh massoud.yega...@gmail.com wrote:

 Original document will be reviewed and edited by a few people.
 Then later it will branched to different variations.
 Also, root document will be translated by different people to their
 own languages.
 The root document, these translated documents and branched document
 will be updated (root changes or better translations).
 
 How to manage this? 

Mark, Massoud, I started to question whether you're actually on the
right track to find the solution to your problem.  In my eyes, the
problem with your approach is that you might not need a VCS in the
first place or at least not *that* sharp tool Git is.  Please don't be
too driven away by the fact Git is currently on the hype and is the
de-facto VCS most new software projects pick (to the point that some
people asking for VCS-related help on non-VCS support forums do not
mention what VCS they are talking about as they imply Git).  Git is
wonderful, but it's tailored to a specific task: managing source code
of a software project by a person with advanced skill set and
consequently matching demands to their tools.  To me, it seems that
your use case doesn't fall into this categorization (yes, I know that
lots of inexperienced folks use Git but the question is should they use
it in the first place).

So, I'd like to ask you both: did you try to explore if one of the
so-called document management systems (DMS) is actually the suitable
fit for your use case?  For instance, the Alfresco project is a mature
and free DMS.  A DMS allows you to inject documents, set up their
workflow (approval, submission to other persons etc), manage their
versions, receive notifications about edits etc.  And all this using
a simple (typically web-based) interface.

Honestly, after reading your questions, I fancy how someone in your
enterprise pulls from a shared Git repository, gets a merge conflict
and... I'm just not sure that will play well, especially given the blob
nature of those MSO documents (IOW, they are unmergeable in a normal
sense).  Do you really want to learn about remote vs local branches in
Git?  Suitable merge strategies to deal with blobs?  I'm not so sure.

Hence I'd suggest to first look at a DMS system and if else fails look
at a centralized VCS (Subversion is a typical goto solution) or at least
a VCS system which mimics a centralized workflow as much as possible --
with Fossil being a good fit.

-- 
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] Use git on microsoft words documents

On Thu, 14 May 2015 18:39:41 +0100
Steve (Gadget) Barnes gadgetst...@hotmail.com wrote:

  Is it possible to use git to manage microsoft documents?
  We have so many files and we need to manage the version, change, 
  languages, etc management.
 
  Can we use git?
[...]
 At the risk of getting flamed for mentioning a differnt dVCS, the 
 Mercurial, (hg), project has a very sneaky extension called zipdoc
 that stores the content of the zip files, (docx are actually zips
 containing XML), and the fact that they belong in a specific .docx,
 (or whatever), file.  On committing such a file it is actually
 unzipped and the constituents either stored, or for an update, diffed
 and then on a pull they are pulled as constituent parts and then
 zipped to reconstitute the original file.
 
 You could either consider using Mercurial or trying to find or
 develop a similar extension.

I wonder what this actually buys: you'll end up with a bunch of XML
files (and picture files, if any, and the Manifest file, and so on),
and the problem is that that XML file representing the content is as
readable as the original .docx.  As they say, “XML combines the
efficiency of text files with the readability of binary files” [1].
I mean, diffing a machine-produced XML files, where a tiny
logical change in a document could result in hefty parts of that XML
swath rewritten is just marginally better than the original problem.

To put it differently, IMO the only way to properly diff MSO documents
is to use tools deriving on MSO libs to actually extract content
sensible to humans from these containers, and somehow use it for
diffing.  I don't know how TortoiseSVN et al manage to use MSO-shipped
COM objects to carry out this task, but they do.

On the other hand, good tools for diffing XML *should* exist given the
ubiquity of this crap in the enterprise sector.  I don't know of any,
but it worth googling or someone might chime in with a solution. ;-)

In either case, I'm afraid both people who asked questions in this
thread are looking for a document management system, not a VCS.
And I'm afraid, setting up diff tools in Git wouldn't be an easily
solvable task for them (please take no offence, guys!).

1. http://harmful.cat-v.org/software/xml/

-- 
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] Help with git reset, please.

On Wed, 13 May 2015 08:29:39 -0700
Michael keybou...@gmail.com wrote:

[...]

 Alright, maybe this is my first point of confusion.
 
 I thought HEAD is where you are at -- which of those letters you
 are pointing to. And, it may also be where a branch tip is pointing.
 
 If I make a commit while on a branch, then HEAD -- which letter I'm
 at -- updates, and the branch tip pointer also updates.
 
 If I'm detached, then which letter I'm at updates, but the branch
 tips do not.

That is correct.

 Based on that, I thought that git reset --soft would change which
 letter I'm pointing at, and leave the branch pointers unchanged.

No.  That would not update a branch pointer only if you would be in a
detached HEAD state: in that case just the HEAD would be updated.

 What you seem to be saying, if I understand correctly, is that being
 at a branch tip does not mean, I am pointing to a letter, and the
 branch tip is here as well, but I am pointing at a branch tip, and
 the branch tip is currently here.

Well, I reckon the key to understand why these things work as they do
in Git is to grasp the concepts of refs and how is the HEAD ref is
special.

As you supposedly know, a ref (short for reference) is *a name* which
points at something which can be resolved to a commit (Git manuals
neatly refer to those somethings using the term commit-ish).
Refs have type, and there are two types: heads and tags.  Most people
call heads branches, and the main Git command to manipulate heads is
called `git branch` as well.  Sure, this adds to the confusion but oh
well.  Heads is a somewhat better name because it underlines that
branches in Git are mere pointers to commits, and commits do not have
special properties which make them belong to a branch (as they do in
Mercurial), and branches in Git can't have multiple heads (as they do
in Mercurial).

Okay, the next thing to understand is that head refs in Git can be of
two kinds: direct (or simple or normal -- you name it) refs point
directly to a commit using the SHA-1 name of it.  A file representing
such a ref merely contains those 40 ASCII characters of the SHA-1 name
it points to.  Another kind of a head ref is symbolic:  such a ref
contains a reference to another ref by including a line of the form:

  ref: refs/type/refname

Normal branches are direct refs, and that's why a branch is said to be
a pointer to a commit.

The ref named HEAD is special because it can be either a direct ref
or a symbolic ref.  If you check out a branch, HEAD becomes a symbolic
ref pointing at that branch.  If you check out something which can't be
moved by committing, HEAD becomes a direct ref.  I'm sure you can now
see that the current kind of the HEAD ref precisely defines whether
you're in a detached HEAD state or not.

Consequently, the rules of how operations on HEAD behave depend on its
current kind: when Git tries to reach for a commit through that ref, it
either does this right away -- if HEAD is direct, -- or has to
*dereference* this ref first -- if HEAD is symbolic.

Now observe, that when you call `git reset --soft|--mixed|--hard`
while you have a branch checked out (and HEAD is symbolic) Git chases
the chain of HEAD - branch and changes the ref representing a branch.
Note that HEAD in this case is not really changed at all!  It just still
points to the same ref as before, just that ref got updated.

Conversely, in a detached HEAD state, `git reset ...` above operates
on the HEAD ref directly (there's nowhere to resolve it) and moves it
directly.

 If that is the case, then the first thing I would need to do to make
 git reset --soft behave the way I think it does is to first go to
 detached head at the same letter (so I am now pointing at the letter
 that the branch tip points to, rather than pointing to the branch tip
 pointer), then I can move head without moving branch tips.

That is correct.

The question is: do you really need to do this?
I'd say bringing just a single file from a dirty devel branch onto
master could be done way simpler (see below).

[...]

 Now, lets say your topic branch is really, really messy, with lots of
 commits, tests, commits, tests, undo, test, change, test, repeat. And
 I really don't want to toss that in as a fast forward. And,
 apparently, using no-ff breaks bisect and blame (1). That means
 either a squash commit (which I've managed to mess up once in two
 uses), or something else. As this was just a single file, I thought
 this would be a simple way to move one file cleanly onto master.

The question is: is it okay for you to make all the changes made to
that file appear as a single commit on master?

If the answer is yes, then:

  $ git checkout master
  $ git checkout devel path/to/the/file
  $ git add -u

The second command will update the specified file with its content
it currently has at the devel branch.
So the only thing left is to add the new contents of the file to
the index and commit.

If the answer is no, things are harder.  A squash

Re: [git-users] Rebase onto history from another repository

2015-05-12 Thread Konstantin Khomoutov

On Tue, 12 May 2015 04:39:32 -0700 (PDT)
J66st vdplas.jo...@gmail.com wrote:

 I have two repositories A and B. A is my working repository. B is a
 bare repository containing a more detailed history than A. This is
 illustrated in the following simplified graphs.
[...]
 A1D1-E--F--G [master]
 
   \  \
 
H--I--J [topic]
[...]
 A2---B2--C2--D2
[...]

 Notice that both histories use identical tag names for tagging
 versions! My first idea is to set repository B as a remote to
 repository A, then fetch from B, rebase E onto D2, then prune A1 thru
 D1.

That is correct.

 But wouldn't fetching from repository B cause the tag names to clash?

You're not forced to fetch tags.
Use something like

  git fetch B 'refs/heads/master:refs/heads/mb'

and you'll get a local branch named mb containing the history of
master available in B.

What I'm more concerned with is that rebasing E onto D2 will surely
break H..J because your E, F, G will turn into E', F', G' with changed
SHA1 names.

So *may be* you will instead want to use `git replace` replacing
D1 with D2 so that E and the descendant commits are left intact.

-- 
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] Restrict users from creating or deleting the remote branches

On Wed, 13 May 2015 19:06:24 -0700 (PDT)
Sakthivel D sakthis...@gmail.com wrote:

 Being a GIT Admin, I need to know how to restrict the users from
 creating a new branch or deleting an existing branch in GIT Remote
 server.

With plain Git, you can't -- that's chiefly because Git being a
distributed system does not draw a clear line between the server and
the clients.

So, if you need to have certain access control to your shared repos,
you have to either install and configure some front-end which mediates
access to these repositories or have a more involved turn-key Git
hosting solution.

Supposedly the most popular simple front-end these days it gitolite.

As to hosting platforms, gitlab and gitblit seem to be popular and
active.  There are also Windows-specific solutions (typically plugging
Git into IIS): Git Web Access, Bonobo Git Server (both are at
codeplex.com).  Of course, there are also commercial solutions
available.

-- 
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] Use git on microsoft words documents

On Wed, 13 May 2015 21:29:18 -0700 (PDT)
Massoud Yeganeh massoud.yega...@gmail.com wrote:

 Is it possible to use git to manage microsoft documents?
 We have so many files and we need to manage the version, change,
 languages, etc management.

What do you mean by managing languages?

 Can we use git?

You can, but note that MSO documents are essentially binary, and it's
impossible to diff them using only built-in Git facilities.

You might not need diffing at all (say, you're fine with just recording
versions and put some information about them into commit messages, and
are not interested in physical changes done to documents between
revisions), and then you should be fine using Git as is.

If you still need diffing, I think you might be better off with
Subversion as there are tools available around it to help dealing with
MSO-produced documents:
* The diff viewer program shipped with TortoiseSVN -- the goto solution
  for working with Subversion on Windows -- has limited support for
  diffing MSO documents.
* There is [1] which integrates support for Subversion right info
  MSO editors and claims to support diffing as well.

I'd note that both products seem to rely on COM components made
available by an installed MSO suite, so you'll have it installed on
machines which would need that diffing functionality.

Otherwise Git (and any other VCS system) will just be used as a tool
to keep manage opaque changes to opaque blobs -- may be just what you
need but supposedly not.

1. https://code.google.com/p/msofficesvn/

-- 
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 checkout files from another branch, based on a filelist from a text file?

2015-05-18 Thread Konstantin Khomoutov

On Sun, 17 May 2015 23:59:23 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

[...]
 I can imagine a solution:
 Checkout files listed in diff_dev+local-dev_files.txt from
 local_dev to dev branch.
 This way I could stash them, and commit by selected groups.
 
 My problem is, that I can not see possibility to checkout files from 
 another branch, based on a filelist from a text file.

Once you have a text file with the list of file names,
just do

  $ git checkout dev
  $ while read fname; do \
git checkout local_dev $fname; done  dev_files.txt

-- 
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] High level usage question

2015-05-18 Thread Konstantin Khomoutov

On Sun, 17 May 2015 17:31:03 -0400
wor...@alum.mit.edu (Dale R. Worley) wrote:

 John Bleichert jbleich...@gmail.com writes:
  I understand that the underlying git principle is that everything
  is local. Is there really no way to compare local to remote?
 
  Alternatively, should I be branching and merging every time I
  switch machines? This seems a strange way to use the tool.
 
  As I said - hi level question and, otherwise, everything works
  fine. 
 
  Am I missing something fundamental?
[...]
 OTOH, if you want to check that *every* ref in your repository is the
 same as the ref of the same name in the remote repository, you've got
 to find a command that will list all the refs in the remote
 repositories and their values, and then compare those values with the
 local values.

Basically, that's what

  git remote -v show remote

does: it reaches for the server behind remote asks it for the
refs/heads/* it has, compares them to the local heads, including their
tracking state, and outputs the results in a human-readable form.

-- 
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] Error when building subversion

2015-04-15 Thread Konstantin Khomoutov

On Wed, 15 Apr 2015 09:08:17 -0700 (PDT)
win-newbie mamta.upadh...@gmail.com wrote:

 I am trying to build subversion and the first time it succeeded.
 However, after that I don't see the timestamp on subversion dll's
 changing at all. In the log, I see messages like these:
 
 the following files have staged content different from both the
 file and the HEAD
 
 Am I missing something? Thanks!

I, for one, fail to see any connection to Git usage (which is the
topic of this mailing list) in your question.  Issues with building
Subversion are supposedly to be discussed on Subversion support
channels, IMO.

-- 
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 openssl version

2015-04-09 Thread Konstantin Khomoutov

On Wed, 8 Apr 2015 13:24:35 -0700 (PDT)
win-newbie mamta.upadh...@gmail.com wrote:

  I installed git-1.9.5 using the windows installer. When I run 
  libneon-25.dll through dependency walker, I see it was linked with 
  MSYS-SSL-1.0.0.DLL and MSYS-CRYPTO-1.0.0.DLL. Are these
  openssl-1.0.1m dlls renamed? I am confused because running strings
  on libneon-25.dll, shows openssl-1.0.1h. 
 
 Thanks for the detailed reply! Really appreciate it. I am actually
 running strings on libneon-25.dll and not on all the modules.
 Dependency walker shows the dll's that would be loaded, but what if
 openssl-1.0.1h is statically built in libneon-25.dll?

To be honest, I did not think about such possibility.
On the other hand, having OpenSSL built in statically (even parts of it)
while at the same time having it linked in dynamically is, IMO, highly
improbable.  Again, only studying the build system can really tell that
for sure.

-- 
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] upgrade gitolite

2015-04-15 Thread Konstantin Khomoutov

On Tue, 14 Apr 2015 23:54:40 -0700 (PDT)
Syaifull Al-Bandary ritnes...@gmail.com wrote:

 Ok, Thank you. I'am sorry.

When asking gitolite folks your question, please be sure to provide way
more information than you supplied to us.  Namely:
* What OS (distribution and its version, in case of GNU/Linux-based OS).
* What version of gitolite you currently have installed.
* What distribution channel have you obtained your gitolite from
  (that is, has it been installed using the OS's package manager,
  or from a source package; if the former, was that a package from the
  standard OS's repositories or from a third-party one).
* What version do you want to have installed.
* Why do you want to upgrade gitolite (what's missing in the current
  release etc).

Otherwise, it's nearly impossible to help you because there are oh so
many ways to get a piece of software installed and running, and
difference in version between the currently installed and the one you
want to be installed might mean no upgrade troubles at all or royal PITA
involving porting of configuration files etc.  For instance, when I
were switching from gitolite v2 over gitolite v3 (Debian Squeeze) the
upgrade wasn't completely automatic and required manual tinkering.

-- 
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: showing more number of insertions deletions than actual

2015-04-14 Thread Konstantin Khomoutov

On Tue, 14 Apr 2015 03:43:12 -0700 (PDT)
rajiv gupta rajiv.s...@gmail.com wrote:

 I cannot share the files as it is confidential
 Yes I am using git on windows.I have set  core.autocrlf=true in
 global list and config settings.

That's most probably the culprit.

Make sure this setting is set to false on all levels where it's being
used and then re-clone the repo.  (It's possible to fix up without
recloning but this, I reckon, will drag us too far away...)

-- 
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] git status shows different status for local and remote drive

2015-04-07 Thread Konstantin Khomoutov

On Sun, 5 Apr 2015 15:21:36 -0700 (PDT)
Andres Suarez webmas...@colservers.com wrote:

 Hi, I have a git repository. This repository is under a Linux
 machine. I also have this repository available on a Windows machine
 under a network drive. I have git installed both on windows and Linux.
[...]
 nothing to commit (working directory clean)
[...]

 When I do git status under Windows using cdm on the network folder I
 get: ***

What is cdm?

[...]
 Changes not staged for commit:
   (use git add/rm file... to update what will be committed)
   (use git checkout -- file... to discard changes in working
 directory)
 
 deleted: explorer/data/plugins/mq.serial/queues/channel-nodes:0
 deleted:
 explorer/data/plugins/mq.serial/queues/channel-nodes:ajxp_conf

The ':' is not a valid character for Windows pathnames -- it can only
appear once in a pathname -- exactly at position 2 in it (if we count
from one), with the first one being a drive letter.
IOW, this pathname has no chance of being correctly manipulated by Git
for Windows running on Windows machine.

 modified:   framework/cli/views/webapp/protected/yiic
 modified:   framework/db/schema/cubrid/CCubridColumnSchema.php
[...]

I can only guess here, but it might have something to do with
end-of-line conversion settings.
Does the project include the .gitattributes file?

See [1] and [2] in general for more info.

 Untracked files:
   (use git add file... to include in what will be committed)
 
 explorer/data/plugins/mq.serial/queues/C81O4T~E
 explorer/data/plugins/mq.serial/queues/CBTQK4~4

These, I reckon, are just 8dot3 filenames automatically created by
NTFS for those two invalid filenames containing the ':' characters.
See [3] for more.

While technically these names (supposedly) refer to the contents of
those files with invalid names, Git's index has no way to know about
this and hence shows these files as untracked. [*]

[...]
 Why this is different? I try deleting the repo and cloning again,
 clean the cache, but always, when doing under Windows I say the same
 status, and when doing under Linux I saw directory clean.

As you can see from the symptoms, the problem has nothing to do with
transfer of Git repository (the fetch part of cloning), and the
problem is rather in the work tree (the checking out part of cloning
-- which creates files as recorded in the index in the work tree).

[*] It's interesting to bring this problem up with the Git for Windows
developers: I wonder if it's possible to somehow inspect the
metadata of a file on NTFS to know its true name and use that to
search it in the index.

1. http://stackoverflow.com/a/5788054/720999
2. http://stackoverflow.com/search?q=[git]+modified+windows
3. http://blogs.msdn.com/b/adioltean/archive/2005/01/27/362105.aspx

-- 
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] Git openssl version

2015-04-08 Thread Konstantin Khomoutov

On Wed, 8 Apr 2015 11:30:11 -0700 (PDT)
win-newbie mamta.upadh...@gmail.com wrote:

 Thanks Konstantin! I have confirmed that those dll's are version
 1.0.1.13 which is 1.0.1m. 2 things I am confused about are:
 
 1. Why would strings report openssl-1.0.1h?

The strings utility merely dumps everything which appears to it as
a text string. They hence may come from anywhere from the module (and
that's why I suggested you to check the OpenSSL DLLs instead).

I'm not sure we're able to do an educated guess about what for libneon
might keep an OpenSSL version string in its module.  I mean, the only
way to know for sure is to read its source code.  I'd not be too
surprised to learn it actually asks the OpenSSL linked to it about its
version string and compares it to some constant.

If you do not trust dependency walker, grab any copy of Microsoft
Visual Studio for C++ (any will do, including ancient versions like 6.0)
and run

  dumpbin /imports libneon-25.dll

so it will list you precise file name of the OpenSSL DLL(s) it expects
to be linked in followed by the lists of symbols to import from each
respective library.

I mean, PE binaries on Windows have fixed and well-documented format --
with special sections for imported and exported symbols.  Sure, any
executable code is able to call LoadLibrary() to load arbitrary DLLs
and then all bets are off, but I doubt libneon (or any other part of
what's bundled with Git) does so.

 2. Why are those msys-* dll's renamed?

As to this, I'd say no more than 3 or 4 human beings on our whole planet
would be able to provide a precise answer right away.  Those persons
are Git for Windows developers, and they do not read this list anyway.

So if I were you, I'd clone the msysgit repo and study its build system.
The official project wiki has detailed instructions about how to get
started with building GfW from source code (that is, using msysgit),
so this will give you a pointer about where to start looking.

(Just in case, it's futile to try to ask for this kind of help on the
msysgit mailing list -- you'll be pointed at the build system anyway.)

-- 
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] Git openssl version

2015-04-08 Thread Konstantin Khomoutov

On Wed, 8 Apr 2015 10:59:42 -0700 (PDT)
win-newbie mamta.upadh...@gmail.com wrote:

 I installed git-1.9.5 using the windows installer. When I run 
 libneon-25.dll through dependency walker, I see it was linked with 
 MSYS-SSL-1.0.0.DLL and MSYS-CRYPTO-1.0.0.DLL. Are these
 openssl-1.0.1m dlls renamed? I am confused because running strings on
 libneon-25.dll, shows openssl-1.0.1h.

[1] lists two 1.9.5 releases with the newer one apparently containing
much fresher versions of OpenSSL.

IMO, running strings against libneon is pretty much useless: if
depends.exe tells you it linked with those MSYS-*-1.0.0.DLLs, it really
means that these DLLs will be pulled in when `git svn` is run (AFAIK,
libneon is only needed for Subversion shim to function; Git itself has
no use of it).  So I'd run strings against those MSYS OpenSSL DLLs to
see what they list as their version.  I've just run strings.exe (from
Sysinternals) against my (quite outdated) Git installation and it
extracted full OpenSSL version from these libs.

1. https://github.com/msysgit/msysgit/releases

-- 
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] Second user defined filter on add or checkout

2015-04-02 Thread Konstantin Khomoutov

On Thu, 2 Apr 2015 03:21:05 -0700 (PDT)
Uwe Bieling a.1.psychi0...@spamgourmet.com wrote:

 I'm using a filter for rcs-keywords expansion. Now i want to use a
 second filter to clean some data inside the project on the same file. 
 
 Are there any posibilities to run the keywords expansion first and
 after this my filter? I don't want to modify the original
 keywords-filter, because it's not mine and i don't want to get
 troubles with updates of this filter.

Create a wrapper script which calls the first printer program and pipes
its output to the second filter program (which has its stdout connected
to that of the script interpreter and then specify the script as a
filter instead of the original one.

In the simplest case, if you have

  *.cfilter=rcs-keywords
  
  [filter rcs-keywords]
  clean = rcs-remove
  smudge = rcs-expand

You could then write a shell script

  #!/bin/sh
  
  set -e -u
  
  usage(fd) {
echo 'Usage: myscript {clean|smudge}'
  }
  
  if [ $# -ne 1 ];
usage 2
exit 1
  fi
  
  case $1 in
clean)
  myfilter -clean | rcs-remove
;;
smudge)
  rcs-expand | myfilter -smudge
;;
help)
  usage
  exit 0
;;
*)
  usage 2
  exit 1
;;
  esac

And then change the definition in .gitattributes:

  *.cfilter=complex
  
  [filter complex]
  clean = ~/bin/complex-git-filter clean
  smudge = ~/bin/complex-git-filter smudge

-- 
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] Deploying a static website to local and production servers

2015-06-03 Thread Konstantin Khomoutov

On Tue, 2 Jun 2015 18:09:25 -0700 (PDT)
Márcio Moreira mar...@verdesaine.net wrote:

 I am sorry I forgot to say previously that Pelican runs on the 
 collaborators laptops. The versioned folder already includes source, 
 output, and other sub-folders and files. The workflow: our
 collaborator will edit the source files; run pelican to generate the
 output files; verify the output files using a browser; and, after
 confirm everything is OK, he/she will commit the changes and push
 them to our local server (origin). 
 
 We need to version control and store on the local server the files
 already available on the laptops.
 
 What we are looking for is a way to copy one of the versioned
 sub-folders (named output) from local server (origin) to another
 server (webhosting), making use of post-update, when origin is
 updated.
[...]

OK, that actually makes things simpler, not harder (though I admit I
don't understand why you have decided to keep the results produced by
Pelican in the same repo).

The hook would basically populate the work tree as before but instead
of running Pelican on the populated work tree, you'd just need to sync
the contents of a single directory in that work tree to the remote
server.  The ways to transfer it remain the same.

-- 
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 date time

2015-06-03 Thread Konstantin Khomoutov

On Wed, 3 Jun 2015 16:29:27 +0200
Magnus Therning mag...@therning.org wrote:

  I've a little request for you.
  What about saving date-time on git stash save command and show it
  on git stash show stash@{xxx}?
  I think it is a useful poperty to save.
 
  What do you think about it?
 
 This is a users' list, it's better to bring stuff like this to
 developers' list: http://git-scm.com/community

Actually, the question is way simpler than it appears.
Answered on the main Git list: [1].

1. http://thread.gmane.org/gmane.comp.version-control.git/270689/focus=270691

-- 
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] Change directory of git repository

2015-06-09 Thread Konstantin Khomoutov

On Tue, 9 Jun 2015 09:43:57 -0700 (PDT)
Hannah Scheibner hannahscheib...@googlemail.com wrote:

 There must be some quick fix but I just can't figure out how to do it:
 
 I initialized a git repository on my local computer, but
 unfortunately at the wrong place, i.e. in the wrong directory. 
 How can I undo this or move the working directory that my git
 repository is synched with?
 
 In my example, instead of initializing my repository
 in /home/git/rep1, I initialized it in /home ... :S

What do you mean by initializing?
Did you just run `git init` in the wrong place and nothing more?
If yes, then just do

  rm -rf ~/.git

and that's all there is to it: `git init` merely creates its
repository directory named .git in the current directory, which it
starts treating as the work tree.

If you've managed to add some files to it (like by doing `git add .`)
then there's nothing bad about it -- Git have just copied the contents
of those files under .git.

After you have got rid of that unneeded directory .git, just go on
and initialize a repository whereever you want it.

-- 
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] Error when merging iscsi/nodes directory from linux to windows because of colon in filename

On Fri, 19 Jun 2015 21:08:00 +0200
Konrád Lőrinczi klorin...@gmail.com wrote:

 Thanks very much for your answer!
 It is really a deeply technical answer.
 Maybe are you one of developers of GIT?

Thanks!  No, I'm a mere enthusiast.

[...]
 As for bare repo it doesn't make possible to edit under Windows, then
 checkout under Debian.
 
 As for the git sparse checkout it is a good idea, but I'm afraid,
 that if I ignore iscsi/nodes path, then this will be OK for Windows,
 but on Debian, in case of a data loss  need of restore, these files
 will be not checked out and restored.

I don't really understand.
One only ever need to check files out if one intends to read them or
modify them (typicall to record another commit).  Well, if you only
need to read files you don't actually have to check them out -- it's
just convenient.

In other words, the work tree in a regular (non-bare) repository
files whose contents are *copies* of objects actually stored in the Git
repository.  To say it differently, the work tree is completely
redundant with regard to the repository.  That's why bare repos
(those used for collaboration) do not have any work tree attached to
them (so nothing is ever checked out of them) and yet they perfectly
store all the history pushed into them.

 Both are partially good solutions, but not fully perfect.

I'm afraid your problem is a red herring.
You only need to check those file out if you intend to *edit* them and
then create a new commit.  While I might fathom a reason for this,
it still appears that the repo produced by etckeeper is to be backed
up, not modified.  To do this, all you need is to just clone your
etckeeper repo to a *bare* repository once and then periodically fetch
new stuff there.

 Should I send the use case to the git developer list?

I dunno.  Let's figure out what's your actual use case first.

-- 
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] Remote differs from local. Wrong push?

On Fri, 19 Jun 2015 03:51:46 -0700 (PDT)
fs...@entornosdeformacion.com wrote:

 after a commit and push from my local branch to the remote one, I can
 see in the server (through the web page) that one of the committed
 files is broken. Differences shown in the commit are incompleted and
 the whole file is truncated. But if I look into my local file,
 everything is ok.
 
 I tried with git diff BRANCH origin/BRANCH and no errors appear.
 So, how can I get the differences between the remote and the local
 file??
 
 And more important, how can I upload my current local file and fix
 the remote one?

Before rushing to fix the sutiation I'd first verify the file is truly
broken.

The thing is, all the stuff in Git repositories is linked using the
SHA-1 hashes calculated over the contents of that stuff.  In other
words, commits link to their tree objects using the SHA-1 hash
calculated over the contents of that tree object; tree objects refer to
the blobs representing their files using, again, SHA-1 hashes
calculated over the contents of those files.  This means, if something
is *that* broken *and* Git does not notice this, it's way more likely
that the underlying filesystem (or disk drive) is hosed rather than the
file is corrupted.  A misbehaving web front-end is also more likely to
happen that the corruption of a file in the Git database.

To verify, you have several options.

The simplest is to first fetch from the remote and then see at the file.

Something like

  git fetch origin

and then

  git show origin/BRANCH:path/to/that/file

or

  git diff BRANCH origin/BRANCH path/to/that/file

If that's OK but you'd like to dig deeper, log into the server, where
the remote repository is located, `cd` to that repository's directory
and look at that file:

  git show BRANCH:path/to/that/file

If you'll notice that the file is indeed botched, return to us for
further assistance.

-- 
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] Error when merging iscsi/nodes directory from linux to windows because of colon in filename

On Fri, 19 Jun 2015 08:41:08 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

[...]
 But when I clone to a Windows machine I get the following error:
[...]
 'iscsi/nodes/iqn.1.com.microsoft:iscsiproxy-target': Invalid argument
 warning: Clone succeeded, but checkout failed.
[...]
 I understand, that Windows doesn't handle colons on NTFS filesystem,

It does, but the colon can only appear once in a pathname, and if it
does, it must be at position 2, and then the first character must be in
range [a-zA-Z].  That is, the colon can only be used to delimit drive
letters from the rest of the pathname.

 but I thought GIT should offer some way to solve such problem.

IIUC, no one was able to come up with a proper way to deal with an
issue like this.  Basically, the only doable thing which comes to mind
is a special flag for the index entries which, if set, would instruct
Git to take the on-filesystem pathname from some other place
(supposedly a special area in the index).  The next thing is to come up
with a way to mangle such filenames (something like that code in
NTFS which produces those 8dot3 tilde+number filenames).  And then
all the code which works with the index on both sides of it should be
taught to use such indirection.

Now the problem is that such a change does nothing to the common case --
managing a source code project -- while requiring quite high development
cost, new index format etc.  So I'm afraid this change is not going to
be added until someone sends a patch series implementing it.

 Any idea how to fix this?
 Maybe using clean/smudge feature?

No, the clean/smudge filters only deal with contents, not with names.

There are two workarounds though both of which revolve around not
checking out stuff.
First, you simply can simply avoid checkout if you'll clone into a bare
repo.  If all you need is to have a backup copy on your Windows
machine, this is the way to go.
Second, you can employ the so-called sparse checkouts which allow
to ignore directory hierarchies when checking out stuff.
That is, you set up your repo to ignore the iscsi/nodes hierarchy and
then check out.  See [1] for an intro.

1. http://briancoyner.github.io/blog/2013/06/05/git-sparse-checkout/

-- 
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] Working Copy on remote not updating

On Tue, 16 Jun 2015 04:08:39 -0700 (PDT)
Chad Baloga cbal...@gmail.com wrote:

 I am fairly new to GIT.

Just Git or git.  It's not an acronym ;-)

 When we do a push to the remote repo, the Working Copy on the remote
 does not get updated automatically.

Do you mean the work tree?  In other words, do you mean the copy of
files which are checked out -- the same as in your local repository,
where you actually change the files and then commit the changes?

If yes, as they say, you're doing it wrong.

Forget about your server for a moment and imagine what should actually
happen when you're sitting here hacking on another feature and then
somebody pushes something to your local repository -- what should
happen?  Do you expect all your changes should suddenly disappear --
being replaced with whatever has just been pushed?
I reckon, your answer would be obviously, no! ;-)

But the thing is, Git absolutely does not care whether a repository
is local or on the server -- Git is able to extract history from
a repository and send it to another Git instance, and it is able to
receive history from another Git instance and place it into the
repository -- end of the story.  Everything else is just policy.

To absorb this idea better, just `cd` to another directory on your
local filesystem and do

  git init .
  git clone /path/to/your/local/repo .
  git branch joke
  git push origin joke

...you'll then find a branch named joke in your original repository.
Is that repository remote?  For our new repository we've just created
in the snippet above -- definitely yes; is it remote in your eyes? --
supposedly no.  The same goes for truly remote repositories: they are
deemed to be remote because no one works in them directly, and they
only get updated (via pushes) and queried (via fetches) from clients.

That's how we arrive to this simple fact: work trees are for
programmers.  The only way to update the work tree is to manually tell
Git you want it based on such and such commit.  There's no way to make
Git somehow automatically update the repository's work tree when
that repository receives new history.

Now there's such thing as hooks: Git is able to run programs
(typically scripts) when certain event happens in the repository --
say, the new stuff has just been pushed and some branches updated.
That's exactly what people who still want to use Git as a deployment
tool use: set up a post-update hook to check out stuff from some
dedicated branch and be done with it.  The hook is also able to
compensate for features lacking in Git-as-a-deployment-tool: it does
not store file ownership and access bits / ACLs.

The final point to consider is that for normal repos (those with the
work tree, that is, non-bare) Git by default disallows pushing to the
branch is which is currently checked out.  This is simply to remove the
WTF-factor when your index all of a sudden is out of sync with the
branch it's based on (read the official GIt FAQ for more).

Because of all of the above, deployment is typically done to a bare
repository which has a post-update hook which uses lower-level Git
commands to populate/update work tree *disjoint* from that repository.
Just google for more, and see [1].

Note that you might consider not using Git for deployment at all.
For instance, things like git-ftp work really OK for PHP projects.

1. https://groups.google.com/d/topic/git-users/Lvv7ByIZZ1o/discussion

-- 
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-http-backend on apache for public pull and private push?

On Wed, 17 Jun 2015 14:27:48 -0700 (PDT)
tobias zellner tobias.zellne...@googlemail.com wrote:

[...]
  But now, something strange happen. I have following behavior:
 
 1. pull work fine for everybody. 
 2. push work for everybody. No credentials are asked.
 
  So now I have a repository that is not protected at all. Just
  everybody can read and write. 
[...]
 well I found my problem. I just did not enable the rewrite engine.
 So the working solution looks now like below:
[...]
 Well stupid problem, simple solution. And well it works now with and 
 without receivepack.

Thanks for the status update!

Starters of the theads which did not receive any responses tend to
crawl back into the hole and do not show up with comments -- possibly
thinking that if no one got interested no one will be interested in the
update.  IMO this is flat out wrong -- in part because we're indexed by
web search engines and in part because not everyone among those who did
not respond were uninterested or did not understand the question; they
might just were unable to help, like I was, for instance.

And now we have a problem and the solution in this thread -- to save the
next guy who manages to google 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] Git Replacing Directory Delimiter (Forward Slash) With Colon

On Mon, 15 Jun 2015 07:05:38 -0700 (PDT)
Steve Penza slpe...@gmail.com wrote:

When using Windows to clone a GIT repository, several files in one
directory are listed with a colon in the file name instead of the
directory delimiter: a forward slash. The files cannot be created in
Windows and they are automatically staged to be deleted.
http://content.screencast.com/users/slpenza/folders/Jing/media/47bd6422-ae7b-4b70-b9a9-4bc46c384b93/2015-06-15_0955.png
Attempting to unstage the files results in the following error.
Updating the Git index failed. A rescan will be automatically
started to resynchronize git-gui.

http://content.screencast.com/users/slpenza/folders/Jing/media/48845a78-251a-47da-b51a-074011d786dc/2015-06-15_1002.png
When viewing the repository from iOS, the files appear without colons
as expected.

I'm sceptical about this approach: viewing the repository from iOS
might mean too much things to reason about. Have you managed to clone
the repository somehow to iOS? If yes, what tool did that (AFAIK, Git
does not run natively on iOS)?

Hence I'd start with exploring the repository innards to really see what
pathnames those files have. You do this by starting with a particular
commit and exploring it with `git ls-tree` and `git cat-file` -- going
through three objects until you find that one which contains the file
of interest and actually records its name.

--
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] Git rebase including initial commit

2015-06-24 Thread Konstantin Khomoutov

On Wed, 24 Jun 2015 10:13:22 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

 How to rebase the following commits?
 
 I have:
 A---B---C  orig
 D---E---F  dev
[...]

Does simple

  git rebase --root --onto orig dev

work?

I've just recreated such a history, and it works for me:

foo% git slog orig
272fee5 C
081df92 B
a75960c A
foo% git slog dev
a3c7485 F
3217145 E
962c0e8 D
foo% git rebase --root --onto orig dev
First, rewinding head to replay your work on top of it...
Applying: D
Applying: E
Applying: F
foo% git slog dev
ae40dbd F
856ba3c E
3fb1f7a D
272fee5 C
081df92 B
a75960c A

-- 
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] Git rebase including initial commit

2015-06-24 Thread Konstantin Khomoutov

On Wed, 24 Jun 2015 11:06:52 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

 $ git rebase --root --onto orig dev
 First, rewinding head to replay your work on top of it...
 Applying: E
 Applying: F
 
 
 The result is:
 A---B---C  orig
 \ 
   E---F  dev
 Still missing the D root of dev.

Can you proof that dev indeed has that D commit?

I mean, miracles are rare and far in between so I'd rather beleive
you're misinterpreting what's in your *real* history.

The thing is, --onto and --root disable the rebase's default logic
for figuring out what part of the tree to be rebased to pick and where
to tuck it onto.  Basically, it's just like saying don't be smart, do
what I said, period.  So to me, it really looks like there's no that
D commit.

What happens if you do

  git rev-list dev

?  Does it really show you all the commits you need?

-- 
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] Git rebase including initial commit

2015-06-24 Thread Konstantin Khomoutov

On Wed, 24 Jun 2015 11:13:26 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

 Branch history before rebase is following:
 $ git log orig --oneline
 61ef11b C
 0458ee6 B
 e714739 A
 
 $ git log dev --oneline
 4f9a02e F
 69eabea E
 dbdf75f D

Are there merges on dev?

That is, what does

  git log --graph --decorate --oneline orig dev

show?  Just two single disjoint lines?

-- 
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] Setting up Git for existing project

2015-06-10 Thread Konstantin Khomoutov

On Wed, 10 Jun 2015 09:29:04 -0700 (PDT)
David VanKirk krik...@gmail.com wrote:

[...]
 That being said, I'm not sure the best practice for getting our
 existing code into Git.  We currently have a Test server and
 Production server, so we have two copies of the code and the
 developers access the code directly on the Test server and make
 changes there.  Because of this, we have code files on the Test
 server that I want in the repository, but in most cases I do not want
 these files to ever make it to the Production server.  So on to my
 actual question, how can add ALL the code on the Test server to the
 repository, but only have a subset of that code identified to deploy
 to the Live server?
 
 I've thought about making the Test code the master branch and
 creating a production branch where the Production code subset would
 live, but when i think through the process of merging master changes
 into the production branch it would see that, without a ton of
 effort, the test-only files would come along for the merge, which
 is not desired.

What do you mean by «test-only files»?

Here's why I'm asking: A complicated project usually undergoes certain
code churn which produces a number of commits, each or which is
imperfect in the sense the state of the project at it can't yet be
sensibly used in production.  At some point, the code base stabilizes
and the process resolves in a commit which can be deemed as fit for
production usage.  (More complicated project might involve several
stages for this, like forking a stabilization branch at some point and
only allowing bugfixes on it, and hence the production version is cut
from that branch.)  The key point here is that imperfect history
leads to a perfect commit.  And so here's my question: do you refer
to the contents of the commits from such development history as test
files?  Or do you wanted to tell that developers create on the test
server some files which exist on the filesystem only during development
and must not exist on the filesystem on the production server?

That's a crucial difference, and hence I'd like to see some
clarification before we move forward.

-- 
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] Problem with the detached head:

2015-06-10 Thread Konstantin Khomoutov

On Wed, 10 Jun 2015 08:28:19 -0700 (PDT)
Bhargavi V umail.bharg...@gmail.com wrote:

 I have the head detached for my remote origin/develop branch.

Terminology warning: the HEAD being in a detached state precisely means
that it's no longer associated with any branch -- that's why it's
detached after all.  So you can't really say that you have the HEAD
detached _for_ some branch: your origin/develop branch still has its
own tip intact -- available through using that name origin/develop.

 I was not sure of my previous actions that resulted this but I
 remember getting a message saying the origin/develop diverged from
 develop (don't know if it is relevant).

Supposedly this only means that you have a local branch named
develop, and it's set to track the remote branch origin/develop.
Tracking is used to assist the user in a common case: when a local
branch is logically bound with a remote branch.  When a local branch is
set to track a remote branch, certain Git commands start hinting you
about the relation of commits in these branches.
You can start with [1] to learn more about this concept.

And no, this is not relevant to the problem at hand.

 Anyways, I tried creating a temp branch and forcing the head of
 origin/develop to that temp but I am unable to solve this issue.

Do you really want to mess with origin/develop?

The origin/develop is a so-called remote branch.
The core idea behind remote branches is that they are sort of bookmarks
to the state of a particular remote repository.  Say, you run
`git fetch origin`, and when it completes your remote branches having
the origin/ prefix are updated to mirror what tips their matching
branches on the remote origin contained when fetching run.
These branches are hence only for reference: they are there to not
require you reach for a remote repository each time you want to work
with a remote branch -- inspect its history, merge with your local
branch etc.  That's why you never work directly on remote branches, and
never manipulate them directly.

I think that your origin/devel is just OK, and the real question is
what do you want to do with the work you did while having been in the
detached HEAD state.  Am I right on this?

If yes, then first make sure you saved your work: tag your HEAD commit
or make a branch out of it:

  git tag temp

or

  git branch temp

It seems that you've already managed to do that though...

The next thing is to decide what to do with those commits.
To me, it appears they were intended to be done on develop instead,
right?  If yes, cherry-picking seems like the best bet.
Inspect what was done on the temp branch using `git log temp`
and identify commits you want on your develop.

Then check the develop branch out and use a series of calls to

  git cherry-pick commit

passing it commits you want to get applied -- starting from the oldest.

(This can be automated but let's not touch this for now.)

1. https://git-scm.com/book/it/v2/Git-Branching-Remote-Branches

-- 
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] moving a directory from one repo to another with commit history

2015-05-27 Thread Konstantin Khomoutov

On Tue, 26 May 2015 23:43:43 +0530
Kalpa Welivitigoda callka...@gmail.com wrote:

[...]
  Following is the output of $ git log --all --graph --decorate
  --oneline
 
  *   9c97cd4 (HEAD, master) Merge tag 'tags/Bdir12'
  |\
  | * af56821 (tag: Bdir12) updating dir1-2
  | * d0b8f8a adding dir1-2
  * 2f4b0ae adding dir1
  * 854521c adding dir1/dir1-3
  * 6f54cfb adding dir1/dir1-1
  * 2ff6f17 adding dir2
  * 0710523 init commit
[...]
 Extremely sorry for the confusion made. Let me explain,
 
 In repoB,
 
 $ git log --oneline dir1-2/
 43b1361 updating dir1-2
 e68c343 adding dir1-2
 
 In repoA,
 $ git log --oneline dir1/dir1-2/
 9c97cd4 Merge tag 'tags/Bdir12'
 
 My question is, shouldn't both of them return the same outcome (it is
 ok not to have the same hash, but the commits in repoB should be there
 in repoA, aren't they?) ?

Ah, I think I understand now, thanks.

The reason for this, apparently, is that tree objects referenced
by commits af56821 and d0b8f8a do not actually hang off dir1 prefix
as `git subtree split` did not know about it (and apparently there's no
way to artifically make it think it's there).

To spell it in other words, the first (and only) commit in repoB which
has dir1-2 under dir1 is the merge commit 9c97cd4.
The commits in the chain produced by `git subtree split` do not even
know about dir1-2 (you can verify this by running
`git ls-tree --name-only -r af56821`) as they refer to tree object
that merely contain *the contents* of dir1-2.

Well, I'm not sure what to do now...

Do running

  $ git log --follow dir1/dir1-2

work for you -- descending into the history to the right side of the
merge commit 9c97cd4?  If yes, I'd stop here.

If not, I'm afraid, some sort of `git filter-branch` mumbo-jumbo will
be required on the chain produced by `git subtree split`: the idea is
to rewrite each commit on that artifical branch with sort of the same
commit but with all its files moved under the dir1/dir1-2 directory
so that both names actually exist in the produced tree objects attached
to the commits in the rewritten branch. Basically something along these
lines (untested):

  $ cd repoA
  $ git branch Bdir12 $(git subtree split dir1-2)
  $ git filter-branch --tree-filter 'mkdir -p ./dir1/dir1-2 
  find . -mindepth 1 -path ./dir -prune -o -print |
  xargs mv -t ./dir/dir1-2' Bdir12
  $ cd repoB
  $ git fetch ..\repoA Bdir12
  ... and continue as before

The script passed to `git filter-branch --tree-filter` is run once
for each commit in the history of the branch being rewritten and will
operate on the work tree of that commit checked out.  The script
creates the target directory hierarchy, then finds, recursively, all the
files and directories in the work tree, except the newly created
directory, and then moves them under that directory.
The new commit produced by filter-branch will have all the files under
dir1/dir1-2.

-- 
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 ignore the file size ??

2015-05-29 Thread Konstantin Khomoutov

On Fri, 29 May 2015 03:00:55 -0700 (PDT)
thomas.bergjuer...@googlemail.com wrote:

 I want to use git for my cisco config backupdir. In the config files,
 there a autogenerated lines with current username and timestamps. To
 ignore these lines, I generated a filter.
 
 snip
 git config filter.ignore_cisco_auto_updates.clean sed -e '/^! Last 
 configuration change at/d' -e '/^! NVRAM config last updated at/d' -e 
 '/^ntp clock-period/d' -e '/^: Written by/d' -e '/^! No configuration 
 change since/d' 
 
 git config filter.ignore_cisco_auto_updates.smudge sed -e '/^! Last 
 configuration change at/d' -e '/^! NVRAM config last updated at/d' -e 
 '/^ntp clock-period/d' -e '/^: Written by/d' -e '/^! No configuration 
 change since/d'
 snip
 
 It works fine with one problem. If there is a username in a filtered
 out line and the length of the username differs from the one in the
 previously commited config, the filesize of the two configs differs
 and git status shows this file as changed. 
 
 Is it possible, to ignore the filesize completly, or are there any
 other Workarounds?

It seems you failed to understand an idea behing the clean/smudge
filters machinery.

IIUC, support for clean/smudge filters appeared because people
mighating from VCS systems of RCS (or even pre-RCS) heritage wanted to
use SCM keywords in the project files -- something like $Id$ which
is expanded by the VCS on checkout to contain, say, the name of the
file, the revision it has been last changed in etc (that is, $Id$
becomes $Id: blah.c r12345 1989-02-12 10:00:00 UTC$).  On checkin
(commit) the VCS removes the content of the keyword changing it back to
its token form (say, an expanded $Id$ keyword becomes just literally
$Id$ again).

As you can see, the contents of the file as seen by those parts of Git
which put it into the object database or compare with blobs already
existing there always see the *normalized* form -- with those RCS
keywords always unexpanded.

In other words, smudge filter *puts* stuff in a file and clean filter
*removes* stuff from the file.  And both filters in the pair MUST hold
an invariant: if the contents of the file did not change after the
smudge filter worked, the clean filter must produce the content
identical to that on which the smudge filter worked when it was called.

Your filters break the invariant by only removing stuff.

Now back to your problem.  I honesly do not understand what happens: in
your case the smudge filter should be a no-op as it would try to delete
stuff already deleted by the clean filter.  So... Are you sure your
clean filter really runs or that it indeed drops the stuff it has to
drop?  To verify this, try inspecting the raw contents of that file.
Something like:

  $ git show --raw HEAD:path/to/your/config/file

I'm not sure --raw will help, so you can do it more manually by
inspecting trees using `git ls-tree` and `git cat-file`.

In either case, you do not need your smudge filter and can (and should)
drop it completely.  While being useless, it might actually hide the
problem of the clean filter not running or not doing its work properly.

-- 
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] Some clarification on what Git is actually doing, please

2015-06-01 Thread Konstantin Khomoutov

On Sat, 30 May 2015 10:53:47 -0700 (PDT)
Tim Dawson trhdaw...@gmail.com wrote:

 I'm fairly new to Git. I've learned how to commit, branch etc.
 
 I'm working on a web site which has problems with cross-browser 
 compatibility.
 
 I have created a branch called 'no-flex' in which I've created new
 files to try out a completely different set of CSS styling to a
 stand-alone web page. This has been successful. I have committed the
 new files in the 'no-flex' branch.
 
 I now want to introduce this new approach to styling to the 'master' 
 branch, which contains files for the entire web site. I need the new
 files so that I can refer to them and probably do a bit of copy 
 paste. If I simply go back to the master branch I think I will lose
 my 'no-flex' files,

No, you won't lose these files.  Since you've committed them, they will
be available via that 'no-flex' branch no matter what you check out or
commit.

Note that, as most (all?) SCMs, Git is generally an append-only
solution -- at least history-wise.  Sure, you're able to delete
branches, and rewrite them, but most of the time you just add stuff to
the repository.

 so I think I need to checkout (i.e. go back to) master and merge
 'no-flex'. Is that correct ?

No, not quite.  See below.

 This will result in my new files becoming part of the master branch.
 But they aren't really part of the main web site, they are just a
 side excursion to try something out. Eventually when I've milked them
 for their content they will become redundant (though I probably won't
 want to delete them from my computer).

That's a very keen observation indeed, congrats with this!

Merging means -- both logically and physically -- bring the changes
made on the branch I'm merging into the branch which is currently
checked out, so yes, in this case merging is not what you need.

 Many of the files in the master branch will get changed radically in
 the process, some may no longer be needed, and there will be some new
 ones. The final result will be a web site that looks much the same as
 now, but whose CSS (and other) files will be incompatible with the
 current version.

Yes, this is understandable.  As to what finally do with your 'no-flex'
branch and its relation to 'master' branch, see below.

 Perhaps this is exactly what Git does best, but I have a few concerns:
 1. What does Git actually do with a file that exists in an un-merged
 branch if I go back to the master branch ?

Nothing at all.   The only ways to lose these files are:
* Delete all the references (tags and branches) which, directly or
  indirectly has the commits containing these files in their history.
* Rewrite histories of such references (via `git rebase`,
  `git filter-branch` etc).

And even after you've tried hard to send your committed files into
oblivion, they will still be recoverable via the reflog mechanism:
Git by default logs all drastic movements of tip commits of their
branches, and this log is kept for a hefty amount of days before
entries in it get expired and deleted.  (Drastic movements are those
which are not due to normal committing.)

 2. Will that file still be visible in the directory tree of my text
 editor ? (I think not)

That is correct.  The whole point of a branch is to provide you with
a line of development separate from all the other lines of development.
So when you check out another branch, Git makes sure your work tree
looks like the state of your project recorded in the tip commit of this
branch.  (Well, untracked files which do not conflict with the files
about to be checked out will be left intact.)

 3. What does Git do if I delete a previously committed file from my 
 directory tree ?

Nothing beyond noticing the file appears to be missing compared to the
tip commit of the currently checked out branch (the HEAD).
You will have an option to confirm your deletion -- by staging it for
the inclusion in the next commit or to undo it.
Git suggests you both of these actions when you run `git status` -- as
Magnus already explained.

 4. When I've finished with the files from the 'no-flex' branch, do I
 retain them in the current version, or unstage them so they become
 untracked (but don't get deleted) ?  This may be a matter of choice,
 but what is best practice ?

Well, first, there's no point to mess with the 'no-flex' branch at all.
What would unstaging its files get to you?  Return the state of the
files recorded at its tip to that it had right before you forked it off
'master'.  But what's the point, really?  You don't supposedly intend
to work on it, as it was a one-off gig, right?  Hence you basically
have several sensible choices:

* Just delete this branch (possibly after implementing the similar
  changes on 'master' -- see below for more).

  The command to do this is `git branch -d` (or -D).

* Rename it to something meaning it's obsolete, like
  'attic/no-flex' or 'closed/no-flex'.

  The command to do this is `git branch -m`.

* Replace it with a tag.  Tags

Re: [git-users] GIT_DIR missing in pre-rebase hook

2015-05-27 Thread Konstantin Khomoutov

On Tue, 26 May 2015 08:14:28 -0700 (PDT)
Nick Kugaevsky n...@kugaevsky.ru wrote:

 It was really suprising when I find out that GIT_DIR variable is
 missing in some hooks.
 
 I want to run hook before executing `git pull --rebase` command, so I
 use `pre-rebase` hook for that. There is GIT_DIR variable in my
 script and as I see it is unset.
 
 Is it expected behaviour or bug?

What piece of documentation made you beleive this environment variable
has to be set when a Git hook (or a pre-rebase hook in particular) is
run?  From what I gather from the git(5) and githooks(5) manual pages,
the GIT_DIR env. variable is supposed to be set by external tools (like
SCMs making use of Git), not by Git itself.  That is, if this variable
is set, Git obeys it (unless the --git-dir command-line option has been
speficied when some of Git programs was run).

The git(5) manual page even explicitly states the following at the
start of its section on GIT_* env. variables:

 These environment variables apply to all core Git commands.
 Nb: it is worth noting that they may be used/overridden by SCMS
 sitting above Git so take care if using Cogito etc.

From the sample pre-rebase script (in a freshly initialized Git
repository) I gather that it just runs various Git commands, and hence
it's supposedly run in the work tree (or in the repository folder in
case of a bare repository).

-- 
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] Some clarification on what Git is actually doing, please

On Tue, 2 Jun 2015 09:32:35 +0200
Magnus Therning mag...@therning.org wrote:

  That's quite a lot to take in with one read-through, so I'll study
  it more carefully as I go forward.
  I'm finding Git a whole lot better than giving files slightly
  different names and trying to remember which one went with another!
 
 Yes, read about it and use it.  That's a good way to learn :)  Also,
 if you are curious about stuff surrounding git I can recommend [git
 minutes](http://www.gitminutes.com/).

I would also recommend The Git Parable [1] -- it's fun to read but
provides a good insight on how data is actually managed by a DVCS.

1. http://tom.preston-werner.com/2009/05/19/the-git-parable.html

-- 
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] branching in a distributed environment

On Tue, 2 Jun 2015 16:08:24 +0200
Magnus Therning mag...@therning.org wrote:

  [...]
  at the next `git fetch` people will see that branch locally and
  they can check it out using
 
  % git checkout -b temporary origin/temporary
  [...]
 
  As a useful shortcut, these days
 
git checkout origin/temporary
 
  will create a local branch named temporary which is set to track
  origin/temporary.
 
  Of course, this shortcut is only to be used by those who understand
  what happens, and why.
 
 This exemplifies the main issue with `git` I think: the developers
 keep on improving on the UI without telling me! ;)

Oops, I actually disinformed you: the correct command would be

  git checkout temporary

That is, if a local branch with that name does not exist but there is a
remote-tracking branch with such name, but only in a single remote
(that is, there is no ambiguity), the command behaves as I outlined
above.  Sorry for the confusion.

-- 
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] branching in a distributed environment

On Tue, 2 Jun 2015 15:37:33 +0200
Magnus Therning mag...@therning.org wrote:

[...]
 at the next `git fetch` people will see that branch locally and they
 can check it out using
 
 % git checkout -b temporary origin/temporary
[...]

As a useful shortcut, these days

  git checkout origin/temporary

will create a local branch named temporary which is set to track
origin/temporary.

Of course, this shortcut is only to be used by those who understand
what happens, and why.

-- 
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] Deploying a static website to local and production servers

On Tue, 2 Jun 2015 07:26:54 -0700 (PDT)
Márcio Moreira mar...@verdesaine.net wrote:

 We are using Pelican, a static site generator, to generate our web
 site. We write markdown formatted text files to a content folder
 and Pelican generates HTML files to an output folder. 
 
 Our goal is that the site could be edited by some collaborators
 sharing its work through a repository on our local linux server.
 Every time a commit is pushed to the local server, we wish the output
 folder (or the complete working dir) is pushed  to another server, a
 production web hosting server:
 
 - Laptop A: complete working copy.
 - Laptop B: complete working copy.
 - Local Server: complete working copy for backup and centralized
 repository.
 - Web Hosting Server: only the output folder content (or complete
 working copy, if we can´t send only the output folder).
 
 My question is how to setup the post-receive hook on local server to
 push the output folder to the web hosting server.
 
 I have been following some posts on the web. They all set local
 server as a bare repository, but I need it to host the complete
 project: source and output files. It seems to me that a bare
 repository can´t act as central repository for collaborators. Is it
 right?

OK, let's digest this piecemeal.

First, you appear to make a false connection between your output
directory and the type of the shared/public Git repository.
Git in either setup does now know about this directory -- that
knowledge belongs only in your static website generator.

Now what you really want to have is a way to check the files present in
some revision of interest to some place where Pelican can pick them up.
With a normal (non-bare) Git repository you get this sort of for free:
by means of having the work tree naturally coupled to the repository
itself.

But that's not required for having your files checked out.  90% of
random HOWTOs you're able to google using git+web+deployment explain
exactly this scenario: there's only a bare repository on the target
server, and the files from the tip commit among those just pushed
get checked out to some arbitrary directory.  Most of the time this is
done via environment variables, namely, GIT_DIR, GIT_WORK_TREE and
GIT_INDEX_FILE environment variables.  POSIX shell pseudocode for a
post-receive hook:

---8---
  #!/bin/sh
  
  set -e -u
  
  GIT_DIR=/path/to/your/repo/on/the/server
  GIT_WORK_TREE=`mktemp -d /tmp/siteXXX`
  trap rm -rf '$GIT_WORK_TREE' TERM INT EXIT
  GIT_INDEX_FILE=$GIT_WORK_TREE/.gitindex
  
  export GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
  git read-tree master
  git checkout-tree -a
  
  pelican --srcdir=$GIT_WORK_TREE --outdir /path/to/output/dir
---8---

The script rolls like this:
1) Sets GIT_DIR to the path of your repo.
2) Creates a temporary directory for the files to be checked out.
   And immediately arranges for it to be removed when the script
   is terminated or exits.
   The name of this directory is assigned to GIT_WORK_TREE.
2) Make up GIT_INDEX_FILE variable pointing to a non-existing
   file under our artifical work tree.  That's fine unless
   the name clashes with some existing file.
3) All these variables are then exported -- in order for the
   git programs called afterwards to see them.
4) The tip revision on master is read into the index.
5) The information from the index is checked out to the
   work tree.
6) Pelican runs.
7) The script exits and our temporary work tree gets deleted.

Sure, there are other ways to do this.  If your web site is huge,
you can make your work tree persistent and use the correct keys to
`git checkout-tree` to make it play well with the files already there.

One last note on hooks: the hook you want to use is supposedly
post-update, not post-receive.  An error in the latter kind of hook
aborts incorporating the history you've pushed while the former kind of
hook only runs when the repository's object database is updated.  Hence
post-receive is for linting -- where you might decide to fail pushing
for some reason, and post-update is for making use of the state just
pushed.

Now let's move on to the deployment phase.
You have used the word pushing so it's unclear if you really mean
using Git to sync whatever Pelican generates with your production
server.
While this is possible -- just turn Pelican's output directory into a
regular Git repository and use `git add -A` + `git commit` there after
Pelican finished running, -- IMO this needlessly complicates things and
I'd better use rsync (or unison or whatever) or git-ftp [1].

1. https://github.com/git-ftp/git-ftp

-- 
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] Deploying a static website to local and production servers

On Tue, 2 Jun 2015 18:09:52 +0300
Konstantin Khomoutov flatw...@users.sourceforge.net wrote:

(Cc'd Nick, who recently asked a question about GIT_DIR.)

[...]
 But that's not required for having your files checked out.  90% of
 random HOWTOs you're able to google using git+web+deployment explain
 exactly this scenario: there's only a bare repository on the target
 server, and the files from the tip commit among those just pushed
 get checked out to some arbitrary directory.  Most of the time this is
 done via environment variables, namely, GIT_DIR, GIT_WORK_TREE and
 GIT_INDEX_FILE environment variables.
[...]

To be more clear, these environment variables are documented in the
git(1) manual page -- that is, the manual of the root git command.
You can get it by running `git help git`.

A good informal introduction to this stuff is [1].

1. https://git-scm.com/blog/2010/04/11/environment.html

-- 
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] Avoid EOL hell

On Tue, 2 Jun 2015 22:09:46 +0530
Rustom Mody rustompm...@gmail.com wrote:

 Setting up for a project in which both linux and windows will be the
 OSes.
 
 After spending some time searching for solutions I am as confused as
 ever. What are the optimum crlf settings so that files (maybe of
 designated types, say
 .c and .h files) are CRLF on windows and LF on linux?

I recommend reading through [1].

In short, core.autocrlf set to auto on Windows should, in theory,
ensure that the text files have CRLF EOLs in the work tree and LFs
in the index and the object store.  But that's, well, in theory, and
you might need to cater for the bogosity of particular tools.

(I'm assuming you're using Git for Windows on Windows.  Cygwin's Git
lives in its own POSIX-y world and considers LFs to be the platform's
native EOLs.  The installer of GfW sets core.autocrlf to auto
by default, and, AFAIK, there's no way to tell it not to.)

1. https://github.com/mono/mono/blob/master/.gitattributes

-- 
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] Keeping history migrating .java to .scala

2015-07-01 Thread Konstantin Khomoutov

On Wed, 1 Jul 2015 07:49:45 -0700 (PDT)
Oliver Schrenk oliver.schr...@gmail.com wrote:

 I want to migrate some legacy java code to scala whilst keeping git
 history intact for each file. The idea was to do a very basic
 conversion first, just doing ssyntactical changes first and have git
 mark it only as a rename and go from there.

Do I understand correctly that conversion also implies explicit renaming
of files (like changing their extension from .java to .scala or
something like this)?

 But already the basic syntax changes push git over the similarity
 edge, so now II have a deleted file, and a new file. My understanding
 is then that I basically loose history as I don't see the full
 history of the new file. `git log --follow file` doesn't work.

Does `git log --follow -M5% path/to/that/file/name` help?
By default, Git uses the similarity threshold of 50% when it tries to
detect file rename, so by tweaking this parameter you could make it
more happy with your changes.

 Can I mark file changes manually as a rename?

No, you can't.
What `git commit` shows you as a rename is just a heuristic intended to
aesthetically please the user -- it's not recorded in the repository as
such in any way.  Each commit in a Git repository references a single
tree object, which references blob objects representing its files and
other tree objects representing its subdirectories, and so on.  Tree
objects contain short (relative) names for their entries and have no
idea about tree objects representing the same directory in past commits.

 Are there different approaches?

Well, one working different approach is to adopt the Git's approach to
your changes rather than trying to go against the grain.  In [1],
the creator of Git explains in detail why Git implements the model which
does not explicitly track files but rather considers them as mere blobs
forming the project as a whole (which is a tracking unit in Git).
(The bottom line of that explanation is that the reference project for
Git -- which is Linux -- could not live with rename tracking, and so
it's absent.)

You will certainly not lose history as it will be available via the
regular parent/child relations of the commits in your repository.
Now you're maintaining the file-based mental model and hence
obviously what you're facing now is a problem.  If you will change your
mental model to consider your whole project as a tracking unit, your
history is all there again.

Please understand that I'm not here to claim that being able to do
`git log -- path/to/file` is worthless but from personal experience I
know that indeed obviously it works only for stabilized files, which
receive only small amounts of changes per commit.  On the other hand,
the -S and -R options to `git log` provide you with a powerful tool
for a larger scale.  And so does `git grep` with its ability to search
through a given commit.  May be those will be enough to make you cope
with the situation without trying to fight Git. ;-)

1. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

-- 
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] git cannot push

2015-07-03 Thread Konstantin Khomoutov

On Fri, 3 Jul 2015 06:58:17 -0700 (PDT)
p...@greenlogix.eu wrote:

 but I cant acess any git-scm.com url since this morning, maybe it's
 down or something

This book is called Pro Git.  Google for it, and you'll find
alternate sources (including paperback offers).

 still, I dont understand why a simple git init creates something
 that is not git (bare) client compatible

Because it's more complicated than that.
The chief reason is that all repos in Git are client, and pushing
into a normal repo (where a programmer works on their files) might
spoil the work of that programmer.  I detailed this problem and
possible solutions to it in my other post to this thread.

-- 
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] git cannot push

2015-07-03 Thread Konstantin Khomoutov

On Fri, 3 Jul 2015 06:15:23 -0700 (PDT)
p...@greenlogix.eu wrote:

 hello,
 
 I cloned a rep I installed on a ubuntu machine (empty rep)
 
 as I add files to that empty working copy, I can commit them (I use 
 SourceTree)
 but once I do the push, I get an error, 
 
 master - master (branch is currently checked out)
[...]

I think that's how the tool you're using tells you about the problem
dealed with in [1] and detailed in [2] (I suspect, plain Git would tell
you a lot more information had you used it insteas of SoureTree).

Basically (if I'm correct with the diagnosis) the problem is like here:

* You have a normal, non-bare repository on your target (server)
  machine.

* This means that repository has a work tree -- where the checked out
  files are kept, and where you modify them and from where you then
  stage these changes to be included into the next commit, and then
  commit.

  It seems, you have the branch master checked out there in the
  remote repo.

* Now you're trying to *update* that branch master in the remote repo
  by your push from your local repo.

It seems a logical thing to you until you try to imagine what would
happen if Git allowed to do such a thing by default (it doesn't).

What would happen is that suddenly the index (the staging area in which
commits are prepared) is no more linked to the tip commit of the
master branch it used to before you pushed.  That's quite a nasty
situation: for a start, you'll be unable to commit your changes, and
`git diff --staged` will give weird results.  That is, by this push
you would pull the rug from under the feet of your work tree in the
remote repository.

What to do about this depends on what solution you're more comfortable
with.  I, for one, prefer pushing to a throw-away branch with a
meaningless name such as temp -- then when I'm back at the remote repo
I just do

  git merge temp

and may be

  git branch -d temp

afterwards to get rid of that branch.

A corollary to this, is that if you're able to reach this local repo
from your remote repo, just *fetch* your data from the local repo
when you're back at your remote repo.  That is, fetch instead of pushing.

Another approach, quite often suggested, is to have a separate *bare*
repository somewhere which is used for exchange by both regular repos.
In this scheme, you would push to that shared reposory and then when
back at the remote repository you'd fetch from that shared one and
merge your changes into appropriate branch(es).

IMO for one-man projects this approach is an overkill unless you have
troubles pushing/fetching directly between all your workplaces (and if
you have, you would typically use some public Git hosting such as
Bitbucket or Github or others).

Yet another approach is to tweak a special configuration parameter in
the remote repo to allow pushes to the currently checked out branch.
Given the situation -- you're doing your first baby steps with Git --
I'd strongly advise against this because after the first such push you
will be scratching your head about what to do next.

TL;DR
My bit of advice: push to a temporary branch(es) in the remote repo
and when back at it, merge from that branch/those branches into the
corresponding local branch(es).  You can then get rid of those temporary
branches or keep them around for the next push etc.
Or fetch, if possible/more convenient.

1. http://stackoverflow.com/q/3191400/720999
2. http://gitready.com/advanced/2009/02/01/push-to-only-bare-repositories.html

-- 
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] git cannot push

2015-07-03 Thread Konstantin Khomoutov

On Fri, 3 Jul 2015 07:33:59 -0700 (PDT)
p...@greenlogix.eu wrote:

[...]
 that's it, I am going back to subversion, I dont have a Phd nor a
 NASA ingeneer degree
 these are way to complicated for just 2 person working on a same
 project
 
 this is geberish, and I repeat, why so much hassel for a first
 commit/push

Yeah, the very creator of Subversion summarized this all nicely: [1].

I'd still advise you to make a habit of going for a short walk to make a
few gulps of fresh air before writing a response -- even if you're not
satisfied, are irritated, angry and whatnot.  Take your time to place
yourself in the boots of the person who just tried to help and spent a
hefty amount of their time doing so, and then received a reply claiming
all the stuff they are versed in is gibberish and so on.  I do not feel
offended, just please try to understand that your personal inability
or dissatisfaction with a technology is not a problem this list is
concerned with or interested about.  Really, when you want to dump
something like this to a mailing list, please tweet or write a blog
post instead.

Have fun.

1. http://blog.red-bean.com/sussman/?p=79

-- 
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] Git diff problem with cvs $id$

2015-07-02 Thread Konstantin Khomoutov

On Wed, 1 Jul 2015 06:37:12 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

 I have two branches and the only difference between them is the cvs
 $id$, which is expanded in one branch and not expanded in the other. 
 
 Is there a way to show git diff as unchanged? 
 Also should not show conflict in case of git merge. 

Two approaches:

1) Simply remove it from the files in both branches, as Magnus
   suggested.

   Another idea is to modify files only in the branch in which
   the tokens are expanded -- simply modify them back into token
   form to read just $Id$.

   After that change, the files will be byte-to-byte identical.

2) If you actually need this tokens expanded for real (that is, to
   contain some up-to-date information, read up on clean/smudge
   filters (use `git help attributes`).

   Basically, you'll need a pair of programs one of which would
   expand those tokens in the data it reads from its stdin
   and write the result to its stdout, and another one would do
   the reverse -- turning the $Id: blah blah$ back to just $Id$.
   This way you have files with expanded tokens in your work tree
   and files with normalized tokens in the repository.  Git will also
   take care to apply clean filters when you do plain `git diff` --
   thus comparing the file in the work tree to its version in the
   repository.

I'd say, usage of VCS keywords these days is questionable.
First, knowing which revision the file came from is only supposeldy
useful for non-compiled code (like programs written in Tcl, Perl, Python
etc), and for cases files could be somehow updated / checked out by the
user individually.
Second, given just the file without any expanded VCS keywords in it,
you still are able to guess which commit(s) it could have came from --
quick googling yields [1, 2] as the top two links.

1. http://stackoverflow.com/a/223890/720999
2. http://blog.endpoint.com/2014/11/finding-specific-git-commit-at-point-in.html

-- 
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] Why commit --fixup uses commit message instead SHA of original commit in resulting commit message?

2015-07-02 Thread Konstantin Khomoutov

On Wed, 1 Jul 2015 00:32:23 -0700 (PDT)
Igor Deyashkin igor.deyash...@gmail.com wrote:

 Let i have these commits:
 
 *  task #2850
 *  task #2850 - #2961
 
 Then i fixuping last commit:

 git commit --fixup=
 
 * bfbfbfbf fixup! task #2850
 *  task #2850
 *  task #2850 - #2961
 
 And I perform interactive rebase. Result will be:
 
 * p  task #2850
 * f bfbfbfbf fixup! task #2850
 * p  task #2850 - #2961
 
 Fixup plased after wrong commit. Yes, this behavior is documentated:
 git rebase -i --autosquash places fixup|squash commits after a
 commit whose title begins with the same …. (see rebase options 
 --autosquashdescription)
 
 But why commit --fixup make this? Why not use SHA in fixup commit
 message like this?

I don't know why --fixup behaves the way it does but when I need to
create a fixup commit, I just commit as usually but make my message
single line reading fixup! bbb.  Then at rebase stage it works as
expected.  To be honest, I did even not know about the --fixup
command-line option of `git commit` ;-)

-- 
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] Error when merging iscsi/nodes directory from linux to windows because of colon in filename

2015-07-02 Thread Konstantin Khomoutov

On Sat, 20 Jun 2015 10:07:17 +0200
Konrád Lőrinczi klorin...@gmail.com wrote:

[...]
   As for the git sparse checkout it is a good idea, but I'm afraid,
   that if I ignore iscsi/nodes path, then this will be OK for
   Windows, but on Debian, in case of a data loss  need of restore,
   these files will be not checked out and restored.
[...]
 If there would be no iscsi drive used on production server and no
 Windows machine used as work machine, then the whole solution would
 be working fine.
[...]

The way you check out files on your Windows box has nothing to do with
the contents of the repository you check these files out from (well,
you will be unable to edit those files but then again they are just
device nodes and hence have no content).

So I'd say using sparse checkout on Windows is a way to go in this
situation.

On a side note, it's interesting how device nodes ended up being
tracked by etckeeper.  I'm not familiar with this tool, so my question
is: does it store ownership and access information of files it track?
Do the same apply to major/minor numbers of device node 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] Git diff problem with cvs $id$

2015-07-06 Thread Konstantin Khomoutov

On Mon, 6 Jul 2015 11:53:26 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

  Remove the it!  If you aren't using CVS those lines serve no
  purpose at all.  Even if you do use CVS the line is of dubious
  usefulness. 
 
 Unfortunately I can not remove them.
 They are in an earlier branch of a software repo, which has more
 thousand files.
 So I need a solution, where I can keep original repo, but still can
 merge with my fork, without solving conflicts in more thousand files
 because of cvs indents.

So which repo contains expanded keywords?  If yours, then do a
recursive `sed` (or whatever) invocation on all that thousand of files
and make a single commit titled Normalize CVS keywords.  Then merge
normally.  If the foreign repo contains expanded keywords, may be
`git rerere` might be of help -- it's specifically designed to remember
how you resolved past merge conflicts.

Still, I can't completely comprehend your situation: the foreign repo
supposedly should contain unexpanded keywords because to me, the only
sensible way to get a repo with expanded keywords is to have it
converted from the source one using some brain-dead tool; or may be you
have just done `git add .` on a CVS checkout?

-- 
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] moving a directory from one repo to another with commit history

2015-05-25 Thread Konstantin Khomoutov

On Sat, 23 May 2015 23:02:46 +0530
Kalpa Welivitigoda callka...@gmail.com wrote:

[...]
  Use the `git subtree` command [*].
  [...]
 
  To elaborate, a pseudocode (assuming a POSIX shell) is something
  like this:
 
$ cd repoB
$ git tag Bdir12 $(git subtree split dir1-2)
 
$ cd ../repoA
$ git fetch ../repoB Bdir12
$ git merge -s ours --no-commit Bdir12
$ git read-tree --prefix dir1/dir1-2 -u Bdir12
$ git commit --edit
 
 Thanks for all the support rendered. I tried the above method and it
 places the directory from repoB to the correct place on repoA. But if
 I log the commits for dir1-2 in repoA (git log dir1/dir1-2), it shows
 only the merging of the tag, not the individual commits for that
 particular directory. But if I do a git log from root of repoA, it
 shows all the commits. Is it possible to have the commits for dir1-2 ?

Given the merge commit, does

  $ git log that_merge_commit^2

show you the proper history line?

That ^2 thing selects the second parent of a commit, and in the
case of a simple merge (two parents) this is the side which has been
merged into -- that is, the tree extracted by `git subtree split`).

On the same note, does

  $ git log that_tag_produced_by_git_subtree

give you the history you're expecting to see?

I mean, we have to tell if you have a problem extracting the history
or the problem properly listing it (or some other problem).

I'd also recommend running

  $ gitk --all

or

  $ git log --all --graph --decorate --oneline

to see a neatly layed of overview of the commit graph in your repo.
In it, it should be easy to see if your merge commit actually has
two parents with the second one having a history extracted from the
source repo attached to it.

-- 
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] Need some advice on git setup -- development files must be run on the server

2015-05-25 Thread Konstantin Khomoutov

On Mon, 25 May 2015 09:30:17 -0700 (PDT)
Chris Fillmore fillmore.ch...@gmail.com wrote:

[...]
 In order to test our changes, the code MUST be
 running on the server -- it can't be run locally on our machines. The
 server in our office is not a production environment, it's a
 development environment. Testing and production servers operate in
 our clients' offices.
[...]
- Team members push changes to the development server
 
 Here's where I need advice. How do you go about testing the code in 
 different git branches on the server?
 
 I am imagining I putty into the server, checkout my branch, run the
 code. Is this possible?

That depends on how do you define possible.
Supposedly you want to ask if it's possible to do the checkout my
branch, run the code bit, right?
The answer depends on what constraints the thing you're using to test
the code has.  I'm not familiar with neither of the two pieces of
technology you've cited so I can't tell for sure.
Surely if the thing has command-line interface so you can run it in
an SSH session and see its test run results somehow printed back, it is
possible.  If not, we need further details on how the thing is
supposed to be controlled when doing its test runs.

 But what's to stop other team members from
 doing the same, at the same time?

Again, suppose you have checked out some version of the code into some
directory on the server's file system.  Now suppose one of your
colleagues did the same with a *different* directory.  Does the thing
allow to run two tests on these different code bases at the same time?

If yes, the problem is solved.

If not, then, again, we need further info on that tool's constraints.
For instance, if it requires the code to always be located in a certain
directory and only allows a single run at any time, I'd solve the
testing problem using a simple CGI script which would receive
a commit hash as a parameter, create some lock file and flock() it,
check out the indicated version of the code, run the tests, delete the
lock file.  That would prevent any of you from running several tests in
parallel.

Certainly that's a poor man's solution, and you might look at a CI
system?  Sure, picking one and setting it properly so that it obeys
your tool's constraints might be harder than writing a brain-dead
solution I outlined above; YMMV.

[...]
 We debated the option of imaging the server to run on virtual
 machines locally on each team member's computer. But I'm not sure if
 this is feasible.

Uh, why not?  Only low-end x86 CPUs (those targetting fanless micro-ATX
etc) do not have support for hardware virtualization these days, and
you needn't run a server-class OS (you mentioned PuTTY so I suppose
your team's using Windows on your desktops) as there's VirtualBox.

And there's even no need to use virtualization on desktops as you can
just use KVM (or Xen or containers via LXC or Docker or any other
light-weight solution) on your server and SSH to these instances.

TL;DR
Given the description I'd vote for semi-automatic solution using a CGI
script because to me this appears to be the solution with the least
possible cost (both implementation-wise and support-wise).
But I'm just guessing.

1. http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software

-- 
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] Git http-backend shouldn't use Webdav

2015-05-26 Thread Konstantin Khomoutov

On Mon, 25 May 2015 13:44:49 -0700 (PDT)
Matthias Lantsch alasar.gogle.su...@gmail.com wrote:

[...]
 But when I am trying to push, I get a 404 header back and a return
 code 22:
  PROPFIND /git/repo/test.git/ HTTP/1.1

JFTR:

The server's part -- maps requests and URIs to actions:

$ git grep -E 'GET|POST|PROP' v1.9.5 -- http-backend.c 
v1.9.5:http-backend.c:  Expected POST with Content-Type '%s',
v1.9.5:http-backend.c:  {GET, /HEAD$, get_head},
v1.9.5:http-backend.c:  {GET, /info/refs$, get_info_refs},
v1.9.5:http-backend.c:  {GET, /objects/info/alternates$, get_text_file},
v1.9.5:http-backend.c:  {GET, /objects/info/http-alternates$, 
get_text_file},
v1.9.5:http-backend.c:  {GET, /objects/info/packs$, get_info_packs},
v1.9.5:http-backend.c:  {GET, /objects/[0-9a-f]{2}/[0-9a-f]{38}$, 
get_loose_object},
v1.9.5:http-backend.c:  {GET, /objects/pack/pack-[0-9a-f]{40}\\.pack$, 
get_pack_file},
v1.9.5:http-backend.c:  {GET, /objects/pack/pack-[0-9a-f]{40}\\.idx$, 
get_idx_file},
v1.9.5:http-backend.c:  {POST, /git-upload-pack$, service_rpc},
v1.9.5:http-backend.c:  {POST, /git-receive-pack$, service_rpc}
v1.9.5:http-backend.c:  method = GET;
v1.9.5:http-backend.c:  hdr_str(Allow, 
!strcmp(c-method
v1.9.5:http-backend.c:  GET, HEAD : 
c-method);

(As you can see, the query part of the URI is stripped before the URI path
hits this code.)

Grepping for PROPFIND:

git% git grep -F PROPFIND v1.9.5   
v1.9.5:http-push.c:#define DAV_PROPFIND PROPFIND
v1.9.5:http-push.c:#define DAV_PROPFIND_RESP .multistatus.response
v1.9.5:http-push.c:#define DAV_PROPFIND_NAME .multistatus.response.href
v1.9.5:http-push.c:#define DAV_PROPFIND_COLLECTION 
.multistatus.response.propstat.prop.re
v1.9.5:http-push.c:#define PROPFIND_SUPPORTEDLOCK_REQUEST ?xml 
version=\1.0\ encoding=
v1.9.5:http-push.c:#define PROPFIND_ALL_REQUEST ?xml version=\1.0\ 
encoding=\utf-8\ 
v1.9.5:http-push.c: if (!strcmp(ctx-name, DAV_PROPFIND_RESP)  
ls-dentry_na
v1.9.5:http-push.c: } else if (!strcmp(ctx-name, 
DAV_PROPFIND_NAME)  ctx-c
v1.9.5:http-push.c: } else if (!strcmp(ctx-name, 
DAV_PROPFIND_COLLECTION)) {
v1.9.5:http-push.c: } else if (!strcmp(ctx-name, DAV_PROPFIND_RESP)) {
v1.9.5:http-push.c: strbuf_addf(out_buffer.buf, PROPFIND_ALL_REQUEST);
v1.9.5:http-push.c: curl_setup_http(slot-curl, url, DAV_PROPFIND,
v1.9.5:http-push.c: fprintf(stderr, Unable to start PROPFIND 
request\n);
v1.9.5:http-push.c: strbuf_addf(out_buffer.buf, 
PROPFIND_SUPPORTEDLOCK_REQUEST, escap
v1.9.5:http-push.c: curl_setup_http(slot-curl, repo-url, DAV_PROPFIND,
v1.9.5:http-push.c: error(Unable to start PROPFIND request on %s, 
repo-url)

-- 
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] Interactive rebase, reorder, squash not working

2015-05-21 Thread Konstantin Khomoutov

On Thu, 21 May 2015 09:39:14 +0200
Magnus Therning mag...@therning.org wrote:

  If you are using the command line I'd start with removing `notepad
  ++` from the equation and go with the default (most probably
  that's `vi`).
 
  I seconds this.
 
  Personally I disagree ;-) I do use a balance of Windows and Git
  tools. (I remember the 70's with real teletypes, especially the
  good bits; but, just the same, if it's OK with you ...;-)
 
 I think you misunderstood me.  My suggestion was to remove notepad++
 from the equation *while troubleshooting*.  Removing possible causes
 of the observed problem one at a time is a rather good strategy when
 troubleshooting, I find.

Yeah, that's what I read from the Magnus's message, too ;-)

Just factor out Notepad++, as it seemed a bit tricky to set up,
and see what happens.  Since and interactive rebase wants to have
an editor, stock bundled vi seemed like a good pick for debugging.
If all works as expected, try to plug Notepad++ back in and concentrate
on doing that thing correctly.

That said, vi as shipped in GfW is indeed a bit long in teeth.
But Vim also has a GUI version which looks just okay on Windows,
and for those, like me, who invested into Vim's steep learning curve,
working in a normal text editor is, well, not a pain, but it just
does not feel right :-)

-- 
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] moving a directory from one repo to another with commit history

2015-05-22 Thread Konstantin Khomoutov

On Fri, 22 May 2015 04:04:43 -0700 (PDT)
Kalpa Welivitigoda callka...@gmail.com wrote:

 My question is basically moving a directory from one git repo to
 another with the commit history for that directory. Let me elaborate
 more.
 
 Say we have two git repositories repoA and repoB with the following 
 directory structure
 
 repoA
  --dir1
 -- dir1-1
 -- dir1-3
  --dir2
 
 repoB
  --dir1-2
 
 I need to move the dir1-2 from repoB to repoA so that the directory 
 structure of repoA will look like the following,
 
 repoA
  --dir1
 -- dir1-1
 -- dir1-2
 -- dir1-3
  --dir2
 
 In doing so, I need to preserve the commit history for dir1-2 as well.
 
 How can I achieve this? Are there any other alternative ways that I
 can achieve a similar outcome?

Use the `git subtree` command [*].

First, use `git subtree split` to produce a synthetic chain of commits
which only touched the directory you need the history of, then fetch
that history into the destination repository and merge it there.
For this, you can either use `git subtree add` or direct
subtree merging [1].

Note that the commits in the chain `git subtree split` produces are
synthetic (i.e. created by `git subtree split`), and their SHA-1 names
do not match to those in the original repository's history.

[*] This command should now be available as part of Git.
If your Git install does not expose it directly, look for it
in the contrib section of your Git install and run it there --
it's just a POSIX shell script.

1. 
https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

-- 
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] moving a directory from one repo to another with commit history

2015-05-22 Thread Konstantin Khomoutov

On Fri, 22 May 2015 14:19:08 +0300
Konstantin Khomoutov flatw...@users.sourceforge.net wrote:

[...]
  Say we have two git repositories repoA and repoB with the following 
  directory structure
  
  repoA
   --dir1
  -- dir1-1
  -- dir1-3
   --dir2
  
  repoB
   --dir1-2
  
  I need to move the dir1-2 from repoB to repoA so that the directory 
  structure of repoA will look like the following,
  
  repoA
   --dir1
  -- dir1-1
  -- dir1-2
  -- dir1-3
   --dir2
  
  In doing so, I need to preserve the commit history for dir1-2 as
  well.
[...]
 Use the `git subtree` command [*].
[...]

To elaborate, a pseudocode (assuming a POSIX shell) is something like
this:

  $ cd repoB
  $ git tag Bdir12 $(git subtree split dir1-2)

  $ cd ../repoA
  $ git fetch ../repoB Bdir12
  $ git merge -s ours --no-commit Bdir12
  $ git read-tree --prefix dir1/dir1-2 -u Bdir12
  $ git commit --edit

-- 
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 checkout files from another branch, based on a filelist from a text file?

2015-05-19 Thread Konstantin Khomoutov

On Mon, 18 May 2015 22:05:48 -0400
wor...@alum.mit.edu (Dale R. Worley) wrote:

 Konstantin Khomoutov flatw...@users.sourceforge.net writes:
  My problem is, that I can not see possibility to checkout files
  from another branch, based on a filelist from a text file.
 
  Once you have a text file with the list of file names,
  just do
 
$ git checkout dev
$ while read fname; do \
  git checkout local_dev $fname; done  dev_files.txt
 
 Even shorter:
 
 $ git checkout local_dev $( cat dev_files.txt )

Sure.

But well, I'm a programmer, and hence when looking at a construct such
as this I'm sort of automatically thinking what happens if
dev_files.txt contains 1000 lines? ;-)  I mean, it will blow up on
a file of hefty size while the `while` construct will handle anything
one shovels at it.

But of course your one-liner is great for a simple case.

 If you're not using bash, use:
 
 $ git checkout local_dev `cat dev_files.txt`

  $() is not a bashism: it's defined in POSIX [1].

1. 
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03

-- 
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] Interactive rebase, reorder, squash not working

2015-05-19 Thread Konstantin Khomoutov

On Mon, 18 May 2015 10:42:54 -0400
Michael Powell mwpowell...@gmail.com wrote:

 I have set the global editor to Notepad++ via a shell script:
 
 #!/bin/sh
 C:/Program Files (x86)/Notepad++/notepad++.exe -multiInst -notabbar
 -nosession -noPlugin $(cygpath -w $*)

Does this really work?  (I mean, did you verify the second line of
your script by running it in Git Bash?)
I'm asking because in a Unix shell (and in cmd.exe too, FWIW) double
quotes do not nest so I'm having hard time trying to understand
what's this line supposed to do.

I also wonder how does cygpath work.  Git for Windows is not a Cygwin
application and I doubt it ships with the program named cygpath.

 Then I proceed with the interactive rebase:
 
 git rebase -i HEAD~3
 
 I want to reorder the second commit to the top. I also want to squash
 the first and third commits to a single commit
 
 I edit for pick 3 suchandsuch, pick 1 suchandsuch, pick 2 suchandsuch,
 for starters (in reverse order), save and exit.
 
 However, when I verify the log, nothing seems to have happened.

This sounds strange to me.  What do you mean by verify the log?
After saving the rebase script and closing the editor, you should see
Git actually working in your console as the `git rebase` command is
rather chatty (by default).  Something like First, rewinding your
HEAD to ... then Applying patch (N/M) etc.  Do you see this?
Anything other there?

-- 
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] moving a directory from one repo to another with commit history

2015-05-26 Thread Konstantin Khomoutov

On Tue, 26 May 2015 22:24:25 +0530
Kalpa Welivitigoda callka...@gmail.com wrote:

[...]
  Thanks for all the support rendered. I tried the above method and
  it places the directory from repoB to the correct place on repoA.
  But if I log the commits for dir1-2 in repoA (git log
  dir1/dir1-2), it shows only the merging of the tag, not the
  individual commits for that particular directory. But if I do a
  git log from root of repoA, it shows all the commits. Is it
  possible to have the commits for dir1-2 ?
 
  Given the merge commit, does
 
$ git log that_merge_commit^2
 
  show you the proper history line?
 
 yes, it is correctly displayed.

Okay, see below.

[...]
 Following is the output of $ git log --all --graph --decorate
 --oneline
 
 *   9c97cd4 (HEAD, master) Merge tag 'tags/Bdir12'
 |\
 | * af56821 (tag: Bdir12) updating dir1-2
 | * d0b8f8a adding dir1-2
 * 2f4b0ae adding dir1
 * 854521c adding dir1/dir1-3
 * 6f54cfb adding dir1/dir1-1
 * 2ff6f17 adding dir2
 * 0710523 init commit

Well, then I don't understand what's your problem with this, really...

Does

  $ git log that_merge_commit^2

display commits

  af56821 updating dir1-2
  d0b8f8a adding dir1-2

or not?

I mean, that Git encantation which provided you with the nice ASCII-art
display of your repository correctly rendered the merge commit 9c97cd4
as having two parents -- with the left (or baseline) commit being
your repoB history and the right side being the history extracted
using `git subtree split` from the repoB.

So... Are these two commits really what you wanted to have or not?
I'm asking because first you state that whatever you get is OK to you
and then you cite the output of `git log ... --graph --all` but do not
tell it looks OK to you.  Hence I can't grasp if you're satisfied with
the situation or need further assistance?  If you do need it, then with
what exactly?

-- 
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] ssh admin git accidentally deleted

2015-07-07 Thread Konstantin Khomoutov

On Tue, 7 Jul 2015 06:28:49 -0700 (PDT)
agnes monest monezone.cl...@gmail.com wrote:

 Dear all , I accidentally delete ssh admin git, unfortunately there
 just one admin so I can't make a change in the config and push to the 
 repository. If there's a way undo the change or make an existing user 
 become an admin or is there any super admin command?
 
 I use git version 1.7.5.4 

Tracked in [1].

Agnes, please take your time to absorb [2] and google for
netiquette+cross+post in general.

1. http://thread.gmane.org/gmane.comp.version-control.git/273501
2. http://linux.sgms-centre.com/misc/netiquette.php#xpost

-- 
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] Visually show file history

2015-07-29 Thread Konstantin Khomoutov

On Wed, 29 Jul 2015 08:26:23 -0700
Ying Huang huangyi...@gmail.com wrote:

[...]
  I'm afraid I don't get your problem statement.
  As I understood it, you told that,
  1) say, let the history of hello.txt includes 3 commits, and
  2) you'd like to see three diff views -- one for each of
  those commits, and
  3) each such diff view should display the changes between
  the indicated commit and its parent commit.
 
  Is that correct?
  Yes, I want to see all 3 of them, each one diff against its
 parent.

OK, thanks.  At least the common ground is now established. :-)

 Say, we have these 3 commits, just for easy:
  commit1
  commit2
  commit3
  I am expecting the following diff running:
  git difftool commit1^! $1

Could you elaborate on why are you keep insisting on using rev^!
instead of rev^1 which, IMO, is a sensbile thing for this case?

From the gitrevisions(7) manual page:

| rev^!, e.g. HEAD^!
|  A suffix ^ followed by an exclamation mark is the same as
| giving commit rev and then all its parents prefixed with ^ to
| exclude them (and their ancestors).

That's clearly a thing from the commit set theory used when pruning
parts of the history DAG to get a smaller *set* of commits out of it.
Let me reinstate this logical chain: 1) A diff tool expects two
references to single commits; 2) rev^1 picks the first (left) or
the only parent -- always a single commit.
rev^! might potentially return any number of commits (bound only by
the total number of commits in your hisory graph); it this really what
you're looking for?  I'd question that.

  git difftool commit2^! $1
  git difftool commit3^! $1
  While, only these two are running:
  git difftool commit1^! $1
  git difftool commit3^! $1
  commit2 is not run. That's my problem, and I don't know
 why..

OK, one immediate thought is that your rev^! simply returns more than
a single entity and then one of the two possible things happen:
* All the list of revisions returned by that operator gets interpreted
  as a single string (according to the POSIX shell rules), and that
  string gets passed to your difftool which then fails to resolve such
  revision string into anything sensible.
* All that list gets passed to the difftool as separate arguments, but
  the tool gets confused about their number.

So...  Could you just freaking try the suggested

  git difftool commit2 commit2^1 $1

approach and see if that works?  Really, that would have saved a lot of
virtual trees already. ;-)

The next thing to try if that fails is to debug.  Do not call difftool,
but rather read up on `git rev-parse` and call it instead to see what
the difftool (or, rather, Git calling it) would think about what you
submit to it.  Make that printed to the console.  See what happens.

-- 
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] Visually show file history

2015-07-28 Thread Konstantin Khomoutov

On Tue, 28 Jul 2015 10:10:40 -0700 (PDT)
颖黄 huangyi...@gmail.com wrote:

   Hi, I am trying to visually show a file change history.
   An easy way to do is to use gitk file, while it is in text
[...]
   My intention is just to show the file change history in a visual
 tool, for exampel my favorite one: kdiff3,
   any alternative solution/help would be greatly appreciated.

The problem with your question is that you presented a solution without
clearly explaining your objective.

Could you please explain in simple words what are you trying to achieve?
I mean, like in
1) I have a commit-ish.  Let's call it abc123.
2) Given it, I'd like to have kdiff3 popped up displaying difference
   between such and such commits.
3) ...

In the meantime, does `git log --patch --follow -- path/to/file`
do what you want (in text mode)?

After doing `git config --global core.ui auto` diffs rendered in the
console look no less understandable than those presented by a graphical
tool IMO.  Well, unless you have insanely long lines in your files
while having small terminal window.

-- 
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] Visually show file history

2015-07-30 Thread Konstantin Khomoutov

On Wed, 29 Jul 2015 16:57:30 -0700
Ying Huang huangyi...@gmail.com wrote:

[...]
  So...  Could you just freaking try the suggested
 
 git difftool commit2 commit2^1 $1
I have changed to
  git difftool $name^1 $name $1
  But some commits are still skipped.
 
  approach and see if that works?  Really, that would have saved a
  lot of virtual trees already. ;-)
 
  The next thing to try if that fails is to debug.  Do not call
  difftool, but rather read up on `git rev-parse` and call it instead
  to see what the difftool (or, rather, Git calling it) would think
  about what you submit to it.  Make that printed to the console.
  See what happens.
  What does git rev-parse do? Will it harm my current git
 repository? I have read the man page but it raised more questions
 than answers.
  Could you give me an example?

`git rev-parse` take a string you give it, tries to interpret it
as a revision or a set of revisions according to the rules specified in
the gitrevisions(7) manual page and then prints the result(s) of
interpreting your revision specification or errors out.

An example on one of my live repositories:

| % git rev-parse HEAD
| 124d295ca0a19f23c241850851f625994e5262ed
| % git rev-parse HEAD^1
| 6f4df7ec5787b9c99bfb6b5246d1765c5ba350e6
| % git rev-parse HEAD^!
| 124d295ca0a19f23c241850851f625994e5262ed
| ^6f4df7ec5787b9c99bfb6b5246d1765c5ba350e6
| ^92f64cf77aac6fc46a24a1bd10715ac07ce46e2a

  Currently I am using echo to see the commit, like bellowing:
 
  git log --oneline --format=%H --follow -- $1 \
| while read name; do
 echo $name;git difftool $name^1 $name $1
  done

Echoing the commit name is now actually bad.

So, do you actually see your `echo` being run tree times?
I'm asking because to me, it's not now clear what do you mean by saying
some commits are skipped.  Do I understand correctly that you expect
your git difftool to be spawned three times in your case?

Now I'd convert the encancation to

  git log --oneline --format=%H --follow -- $1 \
| while read name; do
  echo -n This: ; git rev-parse $name;
  echo -n Parent: ; git rev-parse $name^1;
done

and see what happens.

-- 
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] Visually show file history

2015-07-29 Thread Konstantin Khomoutov

On Wed, 29 Jul 2015 07:48:10 -0700
Ying Huang huangyi...@gmail.com wrote:

 Hi,
  great thanks for your attention,
  Yes,   git log --oneline --format %H --follow -- hello.txt is 
 better than using awk.
 
 git log --oneline --format %H --follow -- hello.txt \
  | while read name; do
git difftool $name $name^1
  done
 
  Unfortunately, if you observe carefully, you will soon find that 
 *_it skipped some commits_*. I strongly doubt the fault is the ^ git 
 operator.
  My solution is using an array to save the output first: see my 
 script bellow:

I'm afraid I don't get your problem statement.
As I understood it, you told that,
1) say, let the history of hello.txt includes 3 commits, and
2) you'd like to see three diff views -- one for each of
   those commits, and
3) each such diff view should display the changes between
   the indicated commit and its parent commit.

Is that correct?

If yes, then if a commit has a name (its sha-1 hash sum) rev,
then the name of its first (or sole) parent commit is rev^1,
and the way to get a difference between them is by passing these
two arguments to a difftool.

Just in case (to remove the possibility of a certain common
misunderstanding), a diff view is always generated between a pair
of commits ignoring any commits which might naturally form a chain
between those commits in that pair.

-- 
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] git fetch doesn't update latest tags on a bare repo.

2015-07-27 Thread Konstantin Khomoutov

On Sun, 26 Jul 2015 22:52:21 -0700 (PDT)
dexter ietf dexter.i...@gmail.com wrote:

  git pull is actually the same as if you write git fetch and then
  git merge.
 
  git-fetch doesn't update anything in your working directory, it
  just download the changes from the remote. Think about it as if I
  ask you what did you change in the code? You tell me, but I don't
  apply it to my version yet; that's what git-merge is for.
 
 Thanks for the reply.
 but i don't quiet get it, since its a bare repo i'm not worried about 
 merging the tree.
 the remote and bare-repo have diverged, i want to get that latest
 data from the
 remote (latest commits, tags etc..). if this doesn't happen, my
 bare-repo will always
 be out-of-date,maybe i'm using the wrong command. git fetch doesn't
 seem to be
 the right command for the job. i hope i'm clear now.

`git fetch`, like most (if not all) Git commands which deal with remote
repos, rely on the so-called refspecs.  A refspec is a portmoneu of
reference specification, and they define what to update with what
when a fetch or push operation is carried out.  If a command like
`git fetch` or `git push` does not receive an explicit refspec on
its command line, it attempts to look one up in the repository's
configuration, and uses it, if found.  Since long ago Git sets up
sensible refspecs in the configuration of your repositories, and so
unadorned `git push` and `git fetch` work most of the time, except when
they don't -- because your expectations contradict what they define.

Let's clone a (bare) repository:

  tmp% git clone git://git.domain.local/test.git
  Cloning into 'test'...
  ...
  Checking connectivity... done.
  tmp% cd test/
  test% cat .git/config 
  [core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  [remote origin]
  url = git://git.domain.local/test.git
  fetch = +refs/heads/*:refs/remotes/origin/*
  [branch master]
  remote = origin
  merge = refs/heads/master

Note that we did not pass any options to `git clone`.
Now observe that remote.origin.fetch configuration variable -- what it
says is that when fetching, Git has to:

1) tell the remote Git to send every ('*') ref under
   refs/heads/ (that is, every branch it has), and
2) forcibly ('+') update local refs with matching names under the
   refs/remotes/origin/ hierarchy.

Those refs under the refs/remotes are what called remote branches.
And that's what get updated when you run `git fetch` in a non-bare repo.

OK, let's now just fetch and see:

  test% git fetch -v
  From git://git.domain.local/test
   = [up to date]  master - origin/master
   = [up to date]  foo- origin/foo
   = [up to date]  bar- origin/bar

As you can see, local Git actually asked the remote one for branches,
and that one told ours that OK, there are three head refs, and our local
Git figured out they match remote branches it already has.

Now let's re-clone the repository with the --bare command-line option:

  tmp% git clone --bare git://git.domain.local/test.git
  Cloning into bare repository 'test.git'...
  ...
  Checking connectivity... done.
  tmp% cd test.git/
  test.git% cat config 
  [core]
  repositoryformatversion = 0
  filemode = true
  bare = true
  [remote origin]
  url = git://git.domain.local/test.git

Do you see there's no default fetch refspec?

OK, so what happens if we just run `git fetch` now?

  test.git% git fetch -v
  From git://git.domain.local/test
   * branchHEAD   - FETCH_HEAD

What it said, is that it tried to fetch remote HEAD and updated the
special local ref named FETCH_HEAD in the local repository.
No local branch was updated.

Now let's pretend you did read the manual page for `git clone`
and figured out it supports an interesting command-line option
called --mirror:

  tmp% git clone --mirror git://git.domain.local/test.git
  Cloning into bare repository 'ir-pdf-gen.git'...
  ...
  Checking connectivity... done.
  tmp% cd test.git/
  test.git% cat config 
  [core]
  repositoryformatversion = 0
  filemode = true
  bare = true
  [remote origin]
  url = git://git.domain.local/test.git
  fetch = +refs/*:refs/*
  mirror = true

Do you see this refspec?  It tells Git to grab every possible ref
(branches, tags, notes and whatever else there might be) and forcibly
update the same-named ref locally -- or create it, if it does not yet
exist.  That's why --mirror: `git fetch` with this refspec would
*almost* mirror the remote repository.  Almost because there's no way
to tell Git to automatically delete what's disappeared from the remote
repo; for this, Git has a separate command
`git remote prune remotename`.

Now back to your concrete issue.

If I were you, I'd `git clone --mirror` your bare repos and use
`git fetch` + occasional `git remote prune` + `git gc --auto` on them.

On

Re: [git-users] Git doesn't detect change, if file modification time is restored to original one

On Wed, 22 Jul 2015 11:17:13 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

 I wrote a search  replace perl script, which recursively searches
 files and replaces text in them. After replace, it restores original
 modification time (mtime) of file.
 
 Interesting, that git status doesn't show replaced changes, if the
 mtime is same as original.
 
 Is there a way to force git status to show changes, even if the file
 dates are the same?

Check out the `core.trustctime` and `core.checkstat` options.

On the other hand, I'd say that even those options won't do what you
want.

See also [1] which contains pointers to interesting discussions in
its most upvoted answer.  From that discussion I gather that `git
status` relies on mtime but creating actual commit still rehashes all
the stuff so may be what's really required in your case is
`git add -f -u` or `git add -f -A`, I dunno.

1. http://stackoverflow.com/q/1778862/720999

-- 
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] adding a remote on a private branch.

On Tue, 21 Jul 2015 23:00:23 -0700 (PDT)
dexter ietf dexter.i...@gmail.com wrote:

 Does it work even if the original cloned branch is off of (P),
 i'm just trying to understand how and why this can work.
 
 (Ma) is Machine A
 (Mb) is Machine B
 
 (P) - parent branch
 
 Ma - clone P, call it Pa
  - create private branch Pva in the same tree,  i want to set the 
 remote as (Pb)
 
 Mb - Clone P, call it Pb
 
 I'm just trying to understand if the above is valid configuration ?
 thanks a lot for your help.

I'm afraid you might have terminological issues here: you can't clone
branches, you can only clone entire repositories (containing branches).

As to whether a branch might track any other *arbitrary* branch -- the
answer is yes.  Git, on purpose, pays absolutely no attention to the
source of the information it manages: the only think it's concerned
with is object names (those string representations of SHA-1 hash
values).  So you might obtain a branch X from a repository A, fork a
local branch L off it and then set your L to track arbitrary branch Y
fetched from a repository B.  X and Y might be the same (in terms of
their history) or may be completely different -- Git does not care;
just in the latter case `git status` et al will tell you your L and Y
are heavily diverged because they contain unrelated disjoint histories.

To understand how Git knows whether two branches are related in terms
of their histories, and how much they are diverged is easy: to get this
information Git uses the same technique as the `git merge-base` command
does, so consider reading its manual page.

As to tracking a branch by another branch, this information is purely
declarative and amounts to a single entry in the .git/config file,
which you will easily be able to locate.

-- 
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] bare repo git gc --aggressive

On Tue, 21 Jul 2015 13:22:56 -0500
John McKown john.archie.mck...@gmail.com wrote:

 I use git at home. I have my normal working directories. I keep the
 associated bare repository on a NAS box (accessed with NFS, if that
 matters). I am wondering if it is a good idea to periodically, say
 monthly, go a git gc --aggressive on the bare repositories which I
 update almost daily.

It won't harm but I'm not sure why spend electrons doing --aggressive
when you can just do --auto in a daily/weekly cron job and let Git
itself decide whether it wants to get real with your repository and
actually repack something there.

-- 
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] Create a new repository out of sub repository

On Tue, 21 Jul 2015 12:37:20 -0700 (PDT)
Dimitris Papageorgiou foryou1...@gmail.com wrote:

 How am I going to use git filter branch?
 I tried this with no effect:
 git filter-branch --msg-filter administrator...
 
 I got a message saying:
 git-rewrite already exists,please remove it
 
 Apart from the message I just do not know how to use this directive
 and the manual confuses me...many commands go with it.

Sorry, but I'm afraid you will unlikely be able to cope with this
issue properly; please consider hiring a Git expert to do it for you.

-- 
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] bare repo git gc --aggressive

On Wed, 22 Jul 2015 06:48:06 -0500
John McKown john.archie.mck...@gmail.com wrote:

   I use git at home. I have my normal working directories. I keep
   the associated bare repository on a NAS box (accessed with NFS,
   if that matters). I am wondering if it is a good idea to
   periodically, say monthly, go a git gc --aggressive on the bare
   repositories which I update almost daily.
 
  It won't harm but I'm not sure why spend electrons doing
  --aggressive when you can just do --auto in a daily/weekly cron job
  and let Git itself decide whether it wants to get real with your
  repository and actually repack something there.
 
 I wasn't sure if using git in my working directory would actually
 pack the remote bare repository when I did a git push. I
 appreciate your response.

Ah, this.
No, it won't.  Your pack files are not transferred directly as Git wire
protocol operates on abstract histories, like hey, the user told me
to fetch branch «foo», and that has XYZ as its tip commit; let's figure
out which graph of objects you need to pack for me to fetch so that my
«foo» looks like yours.

It also helps keeping in mind that remote repositories, even bare,
are not treated by Git in any special way compared to local: you can
fetch into a remote repository, and push from it in the same way you
do in a local repository.

-- 
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] git fetch doesn't update latest tags on a bare repo.

2015-07-23 Thread Konstantin Khomoutov

On Thu, 23 Jul 2015 06:44:41 -0700 (PDT)
dexter ietf dexter.i...@gmail.com wrote:

 i have a bare repo, when i do a git fetch, the remote tags are not
 getting updated, though the 'fetch command' runs successfully. please
 shed some light. thanks.

That's almost zero information in your problem statement.

So, to being with, have you read and understood everything which is
written in the DESCRIPTION section in the `git fetch` manual page?

If yes, have your verified that the behaviour you're experiencing
differ from your expectations given the exact command you're running
and the repository configuration which affects it?

-- 
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] Could not load program git