Re: [git-users] Connection Error While trying to Clone from STASH

[Konstantin Khomoutov]

On Fri, 17 Oct 2014 05:00:48 -0700 (PDT)
Suman M  wrote:

> I'm using GIT to clone one of my repository into local, I'm using cmd 
> prompt to do this. 
> 
> I'm under netwrok firewall ofmy org, when I try to clone it showing
> an *Error Received HTTP code 407 from proxy after CONNECT.*

HTTP status code 407 [1] means "proxy authentication required" which
means you're not only behind a firewall but behind a HTTP proxy [4] as
well.

To use your proxy you have to tell Git how to authenticate on it,
see [2] for one example and [3] in general.

1. https://www.google.com/search?q=http+status+code+407
2. http://stackoverflow.com/a/19213999/720999
3. https://www.google.com/search?q=git+proxy+settings
4. http://en.wikipedia.org/wiki/Proxy_server

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Excluding "Makefile" from a git repo (also for git reset --hard)

[Konstantin Khomoutov]

That's what `git update-index --assumed unchanged is for.
See [1] for more info.

1. https://www.kernel.org/pub/software/scm/git/docs/git-update-index.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] Excluding "Makefile" from a git repo (also for git reset --hard)

[Konstantin Khomoutov]

On Mon, 20 Oct 2014 14:29:58 -0700 (PDT)
Konstantin Khomoutov  wrote:

> That's what `git update-index --assumed unchanged is for.

Sorry, that was meant to be

  git update-index --assume-unchanged 

(I'm not much into typing on the phone).

> See [1] for more info.

Also check if the --skip-work-tree option of this command is of help for
your case.

1. https://www.kernel.org/pub/software/scm/git/docs/git-update-index.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 objects and user permissions

[Konstantin Khomoutov]

On Wed, 22 Oct 2014 09:23:18 -0700 (PDT)
Jon Zeolla  wrote:

> I have some pretty stringent permissions in git (via posix extended
> file attributes), as we attempt to delegate access to pushing certain
> directory structures to certain groups of individuals within our
> team.  
> 
> We had an issue the other day where a user tried to push ("git push
> live") but didn't have enough permission to create the index.lock
> file.  The user did have write permission to the objects and refs
> directories.  The git logs ("git log -p") show that the push had been
> successful, but there are files hanging around in the objects
> directory from this user.  Typically the only files that are in the
> objects directory are from the last user that pushed, but at this
> point there has been at least one successful push since this failed
> attempt to push but the objects from two pushes back still remain
> here.  
> 
> I'm just not sure if these should be here or not...  Or how to clear
> them out.  I did verify that they are valid, and the files that were
> attempted to be pushed via "git cat-file -p ".  Any ideas?

May be try running

  git repack -a -d

to get those objects stuffed into a pack file?

> I also wrote a very detailed question yesterday about this but I do
> not see it here or in my activity log, so I'm not sure what
> happened...  But if that happens to pop up at some point, I apologize
> for the double post.  

Yes, that post has hit my inbox as well as I'm able to see it via the
Google's web interface to this list.

I was about asking why not using, say, gitolite with its "virtual refs"
mechanism allowing you to specify fine-grained rules for who can change
which paths but from that your first post it appears, you're using
several repos on the same filesystem so going through gitolite would
probably be an overkill.

-- 
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-filter-branch : How to filter all commits from an given commit ?

[Konstantin Khomoutov]

On Thu, 23 Oct 2014 01:36:11 -0700 (PDT)
Alcolo Alcolo  wrote:

> I want to change something to only one commit C:
> I can do
> git filter-branch --X-filter 'test $GIT_COMMIT = CHash &&
> do-something' 
> -- --all
> But it's an useless heavy work: only descendants of C (including C)
> need to be scanned.
[...]

Honestly, I'm not really capable of dealing with your problem as stated
but is there really a reason you can't or don't want to use

  git rebase -i C~1

amending the commit C and letting Git take care of the rest?

-- 
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 revision number

[Konstantin Khomoutov]

On Tue, 28 Oct 2014 17:49:55 -0700 (PDT)
guru prasad  wrote:

[...]
> Now my question is if the project version is 1.2.3.4
> 
> then I can put this 1.2.3.4 in the archive version so I can see it on
> the runtime but I also want to be able to correlate the version of
> the config file. The config file has Dev, QA, QA perf, PRD
> 
> Now when I deploy I want to be able to deploy with 1.2.3.4:1.2 (1.2
> being the version of Dev config file) something like this.
> 
> Am I completely off track? Not sure how to individual keep track of
> the 4 config files in the config project folder so that I can deploy
> dev changes separately with dev version number, QA with QA number
> etc.,

It's not really clear what exactly do you want to achieve.

You can't have Git somehow automatically use/track/modify/apply those
version numbers because Git does not know anything about them.
But I suppose you can leverage Git in one way or another to help you
maintaining these version numbers.

What comes to my mind is:

1) Have two special files in your repository: one containing the
   project version and another containing the config version.
   Make the archive generation tool read them but not include them
   into the archive it generates.

   Normally, these files should be empty or contain some template
   values, like "A.B.C.D" and "X.Y" respectively, then, during the
   release cycle of a particular S/W revision, the branch tracking this
   would receive two technical commits: one populating the app version
   file and another one populating the file with configuration version.

2) Use tags of special format understood by the archive generation tool.
   Again, during the release cycle of your software product, once the
   devs release their code, tag it using something like "app-v1.2.3.4".
   Then, when another set of changes is done to prepare a particular
   configuration tag the resulting commit with something like
   "conf-v1.2".

   When generating the archive, use

 git describe --tags --match 'app-v*' 

   to obtain the nearest "application version" tag, then

 git describe --tags --match 'conf-v*' 

   to obtain the nearest "config version" tag, parse out version numbers
   from then and construct the resulting version.

   You can then tag  with a combined tag, say, simply
   "v1.2.3.4:1.2" to be able to easily locate this version afterwards
   when a support request comes in.

3) Just use branches named after version numbers.
   Say, when you're about to start a release cycle of a particular
   version of your software, fork a branch named "v1.2.3.4" off the
   point the dev team blessed as ready for release.
   When you need to apply certain configuration to it, fork another
   branch off "v1.2.3.4" and name it "v1.2.3.4:1.2".

I'm not sure I fully understood your requirements but at least all
that might fuel your imagination.

-- 
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] examples of particularly bad merges

[Konstantin Khomoutov]

On Wed, 29 Oct 2014 13:35:45 -0400
Maurizio Vitale  wrote:

>   recently I've seen a very bad (perforce) merge at work, where we
> had to reconcile two branches that have diverged for  more than a
> year. Perforce, I don't care much.
> In the process of helping with that merge, I created many partial git
> repositories (and in some cases used git-imerge. That helped, but
> even with git large merges are not nice: you see all conflicts in
> some random order, you cannot easily revert part of the conflict
> resolution etc.
[...]
> Does anybody have examples of particularly large/bad merges in any OSS
> project I can use?
[...]

I'm sure you might get better results on the main Git list -- post a
(non-HTML) message to git at vger.kernel.org.

-- 
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 recover from a "Detached Head"

[Konstantin Khomoutov]

On Wed, 29 Oct 2014 23:41:42 -0700 (PDT)
Anthony Berglas  wrote:

> I am trying to do something really simple.  I want to commit local
> changes to a remote repository.  But along the way other developers
> modified the remote.  This appears to be very difficult to do in Git.
> 
> When I finished my changes I did a commit -a.  All good.
> 
> But then the push failed.

At that point, you should have stopped and reached for the goto Git guy
in your enterprise ;-)

The major design principle of Git is that it's a distributed VCS (DVCS).
With this in mind, you should understand that the repository you were
trying to push to is somehow special only by policy ("it's a central
repository for our project Foo everyone uses to collaborate") but it's
not in any way special to Git on either side of the wire.
This is the reason why pushes don't work like in Subversion: the latter
is a client-server system, where commits ever happen and are stored on
the server.

Note that this feature of Subversion you're lamenting actually allows
to create commits of the state which did not ever exist on any of the
clients.  No, really, suppose Alice changes foo.cpp then commits, while
Bob is changing bar.cpp seeing an old state of foo.cpp in his working
directory.  Then Bob commits his changes, and Subversion happily
records this commit even though Bob's changes will surely break with
what Alice committed.

Git, as other DVCSes, won't allow this--the history which is pushed
somewhere must have two crucial properties:
* It must represent the complete state of the project (you can't commit
  changes in just a bunch of files).
* It must descent from the line of history already there (that is, if
  you're trying to push commit D to a branch "master" in a remote
  repository, and that branch currently "ends" with commit B, your D
  has to descend from that B--one way of the other, for instance,
  it's OK to push ...B->C->D but not ...A->C->D).

That's why Git failed your push: it required you to reconcile your
local changes with the changes used to update the target branch in the
remote repository with some other changes you did not see yet.

There are two ways to do that: merging and rebasing.  Both are done
after (or along with) fetching.  What to use depends on the workflow
accepted by your team and the concrete situation at hand.

> git fetch ok.

That was a sensible thing to do.

> So I tried to checkout the origin/master.

...and that wasn't.

origin/master is a so-called "remote branch" or "remote-tracking
branch".  Remote braches are sort of bookmarks which show you which
were the state of branches in a particular remote repository last time
you fetched from it--in this case, the branch "master" in the repository
known locally as "origin".  These branches are not "yours" and thus you
never work on them--they're only for reference.

These are explained well in, say, Pro Git.  My stab at explaining them
on this list is [1].

> That gave me a "detached head", even though it looked like I was on
> head.

Being in a state with detached HEAD means that the HEAD reference which
always points to a state on which the index and the work tree are
currently based is currently pointing at a specific commit rather than
to the tip of some branch.  The difference is that when HEAD points to
the tip of a branch, recording a new commit moves that brach's tip to
that new commit while committing on a detached HEAD merely updates that
HEAD reference and nothing else.

Git moves the repository to this state when you're checking out
something which is not a (normal local) branch--say, a tag, a specific
commit or, as in your case, a remote branch.  The reason is simple:
when you check out a thing like those just enumerated, you don't have a
branch to update with the commits to be recorded.

For some reason, working on detached HEAD is considered an "ace"
practice while there is really nothing special if you clearly
understand the mechanics.  Seasoned Git users routinely go into that
state to try out "crazy ideas"--there's little sense in trying to come
up with a name for a temporary branch to work on when you can just
start working and only *if* it turns out to be useful do something with
these new commits--say, assign a branch to them or tag them.

> It said create a branch so I created abtmp (I do not actually want
> any branches).

Yes, the situation just started to get more confusing.

In fact, Git merely suggested you might want to create a branch, not
said you had to.  The whole reason is that, while being in a detached
HEAD state, you check out some other state, the work done in that state
is sort of lost (not really) but getting hold on it requires some
knowledge not available from most Git crash courses.

> Then merged origin/master back into abtmp (which seems
> the wrong way).

It depends.  You can trivially recover from merging into "a wrong
branch", as explained below, what follows is an explanation of which
side of the merge to pick, and wh

Re: [git-users] Git ancestor/descendant terminogy clarification

[Konstantin Khomoutov]

On Mon, 3 Nov 2014 06:42:56 -0800 (PST)
Vasily Makarov  wrote:

> Git documentation defines commit ancestry as "reachability" of one
> commit from another.
> Formally, this might mean that every commit is ancestor and
> descendant of itself. 
> I've also checked git merge-base --is-ancestor and found it returns
> "true" for same commit passed twice as argument.
> 
> This is formal although not so evident detail, and IMO it changes
> meaning of some git commands/options.
> 
> Does anybody have any thoughts on this?

I'm afraid this question is of so academic we on this list have nothing
to do with it.  If you think this is a documentation bug, I recommend
you to post a message to the main Git list (git at vger.kernel.org).
You don't have to be subscribed to it for posting but please make sure
your MUA doesn't produce a HTML-formatted message as it will be
rejected.  See [1] for more info.

1. https://gist.github.com/tfnico/4441562

-- 
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: How to recover from a "Detached Head"

[Konstantin Khomoutov]

On Sun, 2 Nov 2014 18:26:15 -0800 (PST)
Anthony Berglas  wrote:

> Thank you for all your very considered replies.  The solution I end
> ed up using (without the complex explanations) was
> 
> git push
> # fail
> git pull
> git merge origin/master

This step is not needed: `git pull`, when you're on "master" which is
set to track "origin/master" (we imply this is the case here) will
fetch all the new stuff from "master" at origin and then merge
it into "master".

I would reiterate that `git pull` has too much magic built in so I would
use

  git fetch origin
  git merge origin/master

instead until you do really understand what these two commands do and
how `git pull` combines them.

> # resolve conflicts
> git push
> 
> This should go up the front of any manual of GIT, right after git
> clone. But I have not seen it explicitly that I can recall.  (I threw
> the abtmp branch away)
> 
> My interpretation is that that when you push to a remote it will will 
> follow any direct set of arrows (only) to move origin/master along.

Correct, unless you use "--force" with `git push` *and* the remote
repository allows such forced pushes--they are disallowed by default
for obvious reasons (if these are not obvious feel free to ask).

> I have not read that anywhere though.
> 
> 
> 
> One problem with GIT is that every document author gets so carried
> away with advanced features for obscure branching and even partial
> staged commits(!) that they just lose track of the basics.
>
> For example the Git Basics chapter in the git-scm.com book talks about
> advanced things like staging in the intro (which I would never use,
> just always commit -a) but does not describe how to check in to a
> shared repository and resolve conflicts.  Then the external
> repository chapter does not talk about merging!
> 
> The simple model, which I use, is that there is one shared repository
> used by all developers.  I have a local cache, much like Subversion
> but storing all the history for convenience.  We all normally work on
> head, with branches for releases that are kept very short.  Big
> merges are dangerous and avoided.
> 
> I have seen teams get into big trouble just introducing branches to
> CVS. As code is merged backwards and forwards between the branches
> errors are introduced.  Buggy code often reappears on different
> branches, only to be merged back onto good branches.  But the good
> news is that once you fix the same bug multiple times you get really
> good at fixing that bug.  Of course because of all this merging the
> code could never be restructured which would make the merges
> unmanageable.
> 
> Note that the above is not because of CVS's many, many issues.  It is 
> instead the nature of branching and merging code.  And in particular
> to rely on complex branching rather than having a good module
> structure that makes branching largely unnecessary.
> 
> The idea that people are only staging some file in their working
> directory at particular times during the edit, and then putting
> different staged changes into different branches, and then pushing
> different branches to different shared repositories seems just crazy
> to me.  Broken builds would be the least of the problems.  Maybe a
> team of people as smart as Linus Torvald might be able to handle it,
> but not the people that I have worked with.
> 
> So it is great to have fancy functionality.  But getting the basics
> right is most important.  Using git like Subversion doc should be
> chapter 1, not just left as a something implied.  
> 
> 

The problem is that "basics" is a different thing depending on where
you stand for.

For instance, you take for granted that everyone would use
`git commit -a` for a start and then may be try using "advanced" stuff.
But as one example, here at my $dayjob a bunch of webdevs hired about
2-3 month ago used those partial staged commits all the time even before
they did their first `git merge` (actually, they used `git add --patch`
which provides for even more fine-grained staging).  Why?  Because we
here value clean history and atomic commits and so we focussed on that
first.

You seem to assume that the approach Subversion takes is a de-facto
standard and hence every other tool out there must strive to make
Subversion users feel at home.  While Subversion does indeed have a
great "market share" and is well entrenched in the shops not completely
sold on Microsoft-supplied stuff, and there's nothing really wrong with
the approaches to SCM it implements, Git is just different.  I know
this sounds weak, but no, you can't really make it work like Subversion
because it has been created with different mindset and different goals.

It's like procedural programming languages vs functional: you can write
programs in both, and (typically) you can to a certain extent mimic
approaches from a "foreign" domain in a code written in "native" but it
will look and feel clumsy at best.

The same goes to Git vs Subversion: the key to getti

Re: [git-users] Re: How to recover from a "Detached Head"

[Konstantin Khomoutov]

On Mon, 3 Nov 2014 13:53:51 -0800 (PST)
Anthony Berglas  wrote:

> > For instance, you take for granted that everyone would use 
> > `git commit -a` for a start and then may be try using "advanced"
> > stuff. But as one example, here at my $dayjob a bunch of webdevs
> > hired about 2-3 month ago used those partial staged commits all the
> > time even before they did their first `git merge` (actually, they
> > used `git add --patch` which provides for even more fine-grained
> > staging).  Why?  Because we here value clean history and atomic
> > commits and so we focussed on that first.
>
> How does using snapshots make for clean commits?

I'm not sure about the terminology here.  Any commit (no matter if it's
done locally as in a DVCS or synthesized on the server as in a CVCS)
is a snapshot of the continuous stream of changes.  A developer picks
a state to make such a snapshot using certain logic which lies in such
moot and non-technical terms like the project's policy and common sense.
I mean, no matter what's the difference between, say, your logic and
mine, we both use snapshots when we make commits.

> I would think it would make for broken builds when files are
> forgotten.  You should not be working on three different things at
> the same time.  Commit often, one step at a time.  Push most commits
> to minimize merge issues and allow restructures with minimal pain.

OK, I think we're thinking about different levels of granularity here.
You *appear* as advocating the approach of working on a single feature
at a time.  That's fine and I'm all-pro about this (though in reality
this is not always--and even often--possible).  What I'm talking about
is that very rarely, when working on that single thing, you're able to
structure your changes in such a way that by the time you're ready to
commit, the changes done in the work tree represent exactly one commit.
Often, to make clean and understandable history, these changes *should
have been* done in several consequtive rounds--with each one resulting
in a commit.  But people simply do not work this way, and that's why
Git has fine-grained staging and rebasing: you are able to craft a
series of clean commits from an intertwingled set of changes
implemented in the work tree.

A good indicator of non-atomic commits are commit messages mentioning
the word "and" at least once, like "Implement Foo and also rename Bar to
Quux" (even worse is when a developer picks the major--as they
think--feature the commit implements and describes it solely).
What are separate changes, have to be separate commits.

Sure, that "have to be" is a policy.  A popular one, but surely not a
dogma.  Of course, you're free to use another policy.  The thing is,
with Subversion you can't have that policy (or you're condemned to do
lots of dances with `svn diff` and `patch` and `patch -R` with no
safety belts) and with Git you can have it at the cost of some training
as the tool allows you to do that.

> You do need to structure things properly.  For example, you might
> have a config file that has a standard version checked in but each
> developer tailors it.  In that case do not use the source control to
> manage the differences. Instead, each dev should have both the
> standard and tailored version in their working directory and then
> have some mechanism to chose which to use (e.g. and environment
> variable). 

Sure, absolutely agreed.

> > You seem to assume that the approach Subversion takes is a de-facto 
> > standard and hence every other tool out there must strive to make 
> > Subversion users feel at home. 
> 
> I use "Subversion" as a metaphore for basic source control.  Even MS
> team studio and perforce do the basic shared repository work.  I am
> not talking about Subversion's quirks.

IMO, here exactly lies the problem with your interpretation which I'm
trying to address.  You have just thrown in more weight in the form of
two CVCSes popular in the enterprise world and again cast it as "basic
source control".  Like in "but these two tools work that way as well so
they have to do the right thing".  What I'm trying to tell you is that
there exist different "right things" which work best in different
scenarios.  Distributed VCS implement *an approach* to source control
management which might or might not work well for your requirements.
It's not necessary that what has been written to maintain the source
code of Linux will work equally OK for your project.  You might be
interested in reading [2] which, for me, was quite an eye-opener with
regards of certain "whys" of Git.  I mean, you could see whether that
maps onto your set of requirements or not.

> > Also I think you might check out Fossil [1].  I'd say it's a DVCS
> > with 
> Thanks for the pointer.  But Git seems to have market share, which
> counts for a lot.

Sure, but one might be as well carried too far away with this
philosophy.  Too often on this list we see people who for some reason
decide to adopt (or switch to) Git

Re: [git-users] fatal unresolved deltas error

[Konstantin Khomoutov]

On Wed, 5 Nov 2014 07:13:05 -0800 (PST)
Anjib Mulepati  wrote:

> I was able to push and pull from the git remote till yesterday. I
> don't know (or remember) what I did today suddenly I can't push to
> remote git repo. I am getting following error
> 
> $ git push
[...]
> remote: fatal: unresolved deltas left after unpacking
> error: unpack failed: unpack-objects abnormal exit
> To //myserver/git/apps/myApp.git
> ! [remote rejected] master -> master (unpacker error)
> error: failed to push some refs to '//myserver/git/apps/myApp.git'
> 
> And when I try to clone again I am getting error
> 
> $ Git clone //myserver/git/apps/myApp.git/
> Cloning into 'MyApp'...
> done.
> fatal: unable to read tree 18295307f1270da3c09e3de91890652af4ff7ca8
> warning: Clone succeeded, but checkout failed.
> You can inspect what was checked out with 'git status'
> and retry the checkout with 'git checkout -f HEAD'
[...]

This is a serious problem so please post a message to the main Git list
instead (git at vger.kernel.org)--you do not have to be subscribed to
it for posting but make sure your MUA does not produce an
HTML-formatted message.  Also please make sure to include exact
versions of everything in the picture (client and server OSes, client
Git).  From //myserver/git/apps/myApp.git it appears, that you do not
use server-side Git, just a share (supposedly provided via CIFS, 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] fatal unresolved deltas error

[Konstantin Khomoutov]

On Wed, 5 Nov 2014 08:06:49 -0800 (PST)
Anjib Mulepati  wrote:

> I am getting delivery error for git at vger.kernel.org
> Is that the correct email address(i did replace at)

Yes, see [1] and [2] (which actually references [1]).

What's the DSN?  Could you please provide an error message?
(You can respond to me privately if you so wish.)

1. http://vger.kernel.org/vger-lists.html#git
2. https://gist.github.com/tfnico/4441562

-- 
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] Email Usage

[Konstantin Khomoutov]

On Fri, 7 Nov 2014 06:48:39 -0800 (PST)
Rodrigo Narvaez Leuridan  wrote:

> Hi, I was looking around the documentation trying to find for what
> and how does git uses my email address, and how it can be helpful for
> me this feature.
> 
> I am reading the git documentation, for setup is recommendable to set
> a user.email, I know that this email is used as part of the
> description of the committer but, is there another use for the email?
> May I be able to send notifications or make my own emailList by Git?
> Maybe it will be better not to set this email configuration?

No.  You can make Git send e-mails on commits using its mechanism
called "hooks" (read the githooks manual page) but hooks are just
scripts calling low-level Git commands to extract the relevant info and
then mailing it somehow (usually assuming a POSIX-like OS).

So it's not like you tick some checkbox somewhere and Git magically
starts sending mails anywhere.

-- 
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] http access

[Konstantin Khomoutov]

On Fri, 7 Nov 2014 13:03:08 -0800 (PST)
Craig White  wrote:

> My final target is actually https and likely using mod_authz_ldap but
> I am doing baby steps. This is an RHEL 6.5 box
[...]
> Configuration that is working looks like this but it is clumsy - what
> am I doing wrong?
[...]

You did not tell what your immediate target it and what precise
symptoms of it not being achieved are -- I mean, what Git commands you
run, what are their expected outcomes, how they fail instead what are
error messages on the Git and Apache side etc.

Instead you've just presented one bit of Apache configuration.
I fail to see a problem statement and a question.

-- 
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] Tracking Remote Branch Scenario

[Konstantin Khomoutov]

On Fri, 7 Nov 2014 14:30:05 -0800 (PST)
Baus  wrote:

[...]
> *Then I run the command*
> $ git branch -u origin/master
> Branch rel_010115 set up to track remote branch master from origin.
[...]
>   Local branches configured for 'git pull':
> master merges with remote master
> rel_010115 merges with remote master
> rel_121214 merges with remote rel_121214
>   Local refs configured for 'git push':
> master pushes to master (up to date)
> rel_010115 pushes to rel_010115 (up to date)
> rel_121214 pushes to rel_121214 (local out of date)
> 
> *I see that my pull has changed to master but not my push. What am I 
> missing or misunderstanding?*

Making a local branch "track" a remote branch means defining for that
local branch an "upstream" branch from which it should *merge.*
Basically, the command you've run added something like this to the
local configuration (.git/config file):

[branch "rel_010115"]
remote = origin
merge = refs/heads/master

Note that there's no "push = " or something like this.

Instead, to define the way the local branches are pushed when the user
does not explicitly specify what to update with what, you should tweak
the push.default configuration option.  It has lots of values, and the
current default with git < 2.0 is "matching" which means only branches
already existing in the remote repo with names those of local branches
are pushed.  Git 2.0 changed this default to "simple".

I strongly urge you to read the gitconfig manual page, searching for
the options starting with "branch." and also study the section on
push.default.

I reckon the reason for Git having these things working the way they
are is that Git wasn't created with the centralized workflow in mind
(in which you only ever push to a single repository, and always to the
branch you've based your local branch on).

The results you're observing is due to your push.default being
defaulted (or set explicitly) to "matching".  Switch it to "upstream"
or "simple" (for Git >= 1.9) to make relations between your refs for
pushing look the way you want them.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] what is manifest file?

[Konstantin Khomoutov]

On Mon, 10 Nov 2014 03:00:34 -0800 (PST)
Naveen Shreevatsa  wrote:

> What is manifest file? what does it contain? what is it use? 
> is it same as .plf file in perforce?

Git does not have anything named "manifest file" among its concepts,
so what are you talking about?  We need more context.

-- 
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 to FTP Location

[Konstantin Khomoutov]

On Mon, 10 Nov 2014 14:26:42 -0800 (PST)
Johan Lijffijt  wrote:

> Is it possible to use a ftp location as a git repository? 
> What are the commands to do this?

It was possible some long long time ago but it's not anymore (due to
locking issues etc).

Note that if you for some reason want to use FTP to access a Git
repository, it might turn out you really want `git-ftp` instead.

-- 
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] Searching for a changing in a history of a file

[Konstantin Khomoutov]

On Thu, 13 Nov 2014 05:50:18 -0800 (PST)
pep...@googlemail.com wrote:

> I have to know, if a method in a source file was changed in the past.
> I cannot search for the commit messages because I do not know, if a
> good commit messages was written.

Typically you want `git blame` for this task but there are other
approaches as well -- for instance the searching facility of `git log`:
you can its -G command-line option to find a commit in which a
line matching the  was introduced, like in

  git log -Gfrobnicate -- path/to/file.c

Also see the description of the "-S" command-line option of `git log`.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] how to fetch .git repo and additional changes for an existing project

[Konstantin Khomoutov]

Well, two things here.

First, is how to get your repo to the server.
You can either fetch (clone) it from another machine
or initialize an empty repo and then push to it
from another machine.
For the first method, you have to have network
connection on the server, and the machine
holding the source repo should be enabled for transfer
(usually this means SSH). You have told us exactly
zero information about your setup so it's hard to
give more detailed suggestions.
Possibly the easiest is to clone a replica held on
Github then set up something to provide pushing
on the server (SSH may be) and push directly from your dev box.

Second is the what to do with the data which is already
on the server.
If it has any local modifications to your HEAD on the
Dec box, you'll want to copy the changed files over
into the server's repository's work tree and record
a commit.

P.S.
You should definitely read a book on Got to get the
idea of how network-connected repos communicate.

-- 
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 1.9.4‏ for window prompt sh.exe: /dev/null No such file or dirctory

[Konstantin Khomoutov]

On Fri, 14 Nov 2014 23:59:27 -0800 (PST)
Vasily Makarov  wrote:

> There is no /dev/null on windows indeed.
> You may use Git for windows  or Github for 
> windows  to access git CLI on windows.

git-1.9.4-preview20140929 is Git for Windows.

[...]
> > I just install git-1.9.4-preview20140929 on my notebook pc, window
> > 7 64 bit system. When I run git for the first time I got error
> > message;
[...]

-- 
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] Merge without replacing the outdated data.

[Konstantin Khomoutov]

On Tue, 18 Nov 2014 05:26:08 -0800 (PST)
Dmitry Moscow  wrote:

> I have some special task which is definitely out of everyday git
> practices scope. Please let me know if its possible to accomplish
> this with some hacks.
> 
> I have two branches of development of a single product. These two
> branches diverged long ago. Now its time to merge them. The idea is
> to merge them without losing functionality. This means I dont want
> merge them simply by selecting most up-to-date version, I want BOTH
> versions to be present in case there are some difference between the
> files. 
> 
> I.e. if some file differs in two branches - I want to raise a
> conflict to merge it manually. Note, that if file to merge has
> different versions in braches to merge - this does not necessarily
> forces Git will to raise a conflict. It will do it ONLY if there were
> conflicting changes after the branch separation point. This may not
> be my case all the time. For example, in this situation Git will do
> merge without a conflict, and I will just lose the branch A
> functionality in the lines 34 and 67. But I want to preserve ALL
> functionality from both branches:
[...]

You could try going one level deeper and use `git read-tree` instead:

  git read-tree -m HEAD 

This command should only update the index and do not touch the work
tree.  So any files with conflicts will be marked in the index as such
(with their "sides" available).

Note that this command creates a situation of the work tree being not
consistend with the index.  I mean, if the merge operation added some
files, they'll be missing from the work tree, and if it deleted some
files (which our side did not touch, so it's fine to delete them),
they'll be present in the work tree and deemed to be "untracked" by
`git status`.
Hence after fixing the conflicts you'll want to use
`git checkout-index` to update the work tree to the actual post-merge
state.

-- 
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] Upload data to Git Server using Magento 1.9 and NETBeans Version8.0

[Konstantin Khomoutov]

On Tue, 18 Nov 2014 12:46:56 -0800 (PST)
Fernando Lucas  wrote:

> To whom it may concern, we are using GIT to perform code versioning
> when developing an e-commerce in Magento Community 1.9 with NETBeans
> version 8.0 as a development tool.
> 
> The synchronization to download (pulling) the code from the GIT
> server works perfectly. All the code is downloaded into our computers.
> 
> We apply the code changes locally and when we try to upload (Push )
> the data once the wizard is completed, the following error message
> appears: 
> 
> ==[IDE]== 18/11/2014 18:32:37 Expandindo - clone1
> git branch
> git remote -v
> setting up remote: origin
> git submodule status
> git push 
> ssh://99.99.999.999:22//home/ubuntu/public_html/99.999.999.999/public/.git/ 
> refs/heads/master:refs/heads/master
> Atualizações do Repositório Remoto
> Atualização da Ramificação : master
> Id Antigo: 6527df498f7fd60dfd72c8389e1e7529b0935426
> Novo Id: 69c2a2e85b8a63b3ace61234b064746904d71142
> Resultado: REJECTED_OTHER_REASON

NetBeans (as well as Eclipse) does not actually use Git but rather a
custom library, JGit, which is a pure-Java software implementing
support for Git repository format and Git wire protocols.

>From googling by JGit+REJECTED_OTHER_REASON, it appears [1] that
this error code is returned by JGit which it does not know the exact
reason for rejection.  [1] also hints that it's possible, in theory,
to ask the library for an explanatory message but seemingly NetBeans
does not attempt doing this.

> Atualizações do Repositório Local
> Atualização da Ramificação : origin/master
> Id Antigo: 6527df498f7fd60dfd72c8389e1e7529b0935426
> Novo Id: 69c2a2e85b8a63b3ace61234b064746904d71142
> Resultado: NOT_ATTEMPTED

This one is simpler -- see [1] as well.

In this situation I'd try to push the same changes using regular Git
and see what happens.

1. 
http://download.eclipse.org/jgit/docs/jgit-2.0.0.201206130900-r/apidocs/org/eclipse/jgit/transport/ReceiveCommand.Result.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] How to clear history of all repo url that has been accessed from local machine?

[Konstantin Khomoutov]

On Sun, 30 Nov 2014 15:32:45 -0800 (PST)
OC0915566  wrote:

> My company is upgrading the laptops and so, they're selling the old
> ones. The problem is, we've been using the old laptops to access
> remote git repos and the employer would like to clean all possible
> traces of repo URLs that have been accessed in these laptops. How do
> I do this? We used Git Bash and Conemu. Will uninstalling Git Bash
> and Conemu be enough to delete all repo URL history in the laptops?
> or are these repo URL never been saved to local disk in the first
> place? Thanks

As to Git bash, the answer is "most probably yes" because bash saves
the input history to a file under the user's home directory (and you're
probably deleting the user profiles [1]).  As to Conemu, the answer
is also "probably yes": "native" Windows software tends to use registry
for storing all kinds of random stuff, including history, and
contemporary programs would store this data in a personal user's
registry hive (which is just a set of files under the user's home
directory) so if you're deleting user profiles [1] you're deleting this
data as well.

Looking at the issue from another perspective... does knowing URLs of
those repos give away that much to a prying eye?  What matters is
repository contents not where that contents is located.  If you have
some private repos accessible publicly then have them properly
protected -- say, by using SSH keys, and have these keys properly
maintained.

Note that if you're absolutely paranoid (and you might have reasons to
be [2]), you have to wipe (and I mean it, not just format) hard drives
and then install Windows there (either from a rescue partition/DVD if
you're using whatever the vendor installer or from your own images).
If the buyer does not care much, installing FreeDOS after wiping could
be just fine.  It really depends on the expectations.

[1] If not, you really have to.
[2] When you're deleting an object from the filesystem, the object's
data stays intact and can be recovered using specialized software
unless it happens to later be overwritten by other filesystem
operations (typically -- storing new files).  Google for "TestDisk"
as one popular example.

-- 
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 clear history of all repo url that has been accessed from local machine?

[Konstantin Khomoutov]

On Mon, 1 Dec 2014 08:25:03 -0600
John McKown  wrote:

[...]
> > ​You should really ask this sort of question on a "data destruction"
> group. It really isn't a git thing.​
> 
> But since I'm already flapping my jaws: Personally, I would use
> something like a "disk wipe utility". I am not really a Windows user
> (I use Linux), but you can Google for it to get some good hits. Such
> as: http://www.diskwipe.org/ which is not to be taken as a
> recommendation by me for this product, but is just an example. There
> are many such. If you are really worried about proprietary
> information, then I'd strongly suggest getting a "DOD quality" wipe.
> Another thing to think about is the other software on the laptop,
> especially the Windows. Windows in _NOT_ free! And you really should
> see what it would take to transfer the Windows license on the
> existing hardware to a new user. The same with any other "non free"
> software. If you don't, your company _might_ be libel to the
> copyright owners and be subject to being sued. I'm not really too
> sure of this latter, but if this is a large enough company, I'd run
> it by the legal department just for comfort.

By the way, this thought crossed my mind as well when I was writing my
response.  EULA explicitly prohibits relicensing, so yes, while IANAL,
I concur that consulting legal department would be a good thing.

-- 
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 clear history of all repo url that has been accessed from local machine?

[Konstantin Khomoutov]

On Mon, 1 Dec 2014 12:35:38 -0500
wor...@alum.mit.edu (Dale R. Worley) wrote:

> > From: OC0915566 
> 
> > My company is upgrading the laptops and so, they're selling the old
> > ones. The problem is, we've been using the old laptops to access
> > remote git repos and the employer would like to clean all possible
> > traces of repo URLs that have been accessed in these laptops. How
> > do I do this?
> 
> At the least, "reformat" the disks to destroy *all* the current files,
> because many places on the disk is evidence of past activities.  You
> need to be more careful if the information you are trying to remove is
> truly valuable to outsiders.

It worth reiterating that mere reformatting does not destroy the data.
These days, "quick" formatting means merely recreating the filesystem
metadata (a small fraction of space on a typical particion) while "full"
formatting means the same plus scanning the blocks to detect those
which are "bad" (unreadable) -- a feature which is hardly needed on
today's hardware which performs internal remapping of failed sectors.
See [1] for more info.

Hence the only way to ensure safety is wiping disks (which is typically
done by filling all addressable space on the drive by random (or
specially cooked) data, several times).

1. http://support.microsoft.com/kb/302686

-- 
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] Different behaviour for git add with ignored files

[Konstantin Khomoutov]

On Tue, 2 Dec 2014 14:42:27 +0100
Guilherme  wrote:

> In my .git/info/exclude i have the patterns:
> 
> !COM/config/Project.gny
> (...) other ignores
> /COM/config
> (...) more ignores
> 
> When i do
> 
> git add -- COM/config/Project.gny
> 
> I get no warnings or abort about the ignored path (as i expect) but
> 
> git add -- COM/config/Project.gny COM/otherfile.c
> 
> It outputs:
> The following paths are ignored by one of your .gitignore files:
> COM/config
> Use -f if you really want to add them.
> fatal: no files added
> 
> I don't understand the difference in the behaviour. Is this intended?

To me, this appears to be a bug.

One possible reason for observable irregularity in behaviour is that the
Git code may contain a shortcut dealing with the case of a single file.
Dealing with several pathspecs at once supposedly requires first sorting
them to remove duplicates, accounting for "generality" cases like

  git add somedir somedir/somefile

(where some pathspecs are essentially no-ops) and so on, hence I may
well beleive there is some sort of a shortcut which jumps right to the
actuall adding of the file is there's just a single pathspec passed.
Quite possible the "full" code path contains a bug.

Of course, my guess is quite wild and may be completely wrong, but I'm
still inclined to deem what you reported as being a bug.

In any case, to be useful, your bug report shold be rather more
complete:
* What precise version of Git are you using (run `git --version`).
* What OS it runs on?

And bugs should be reported on the main Git list which is
.  It's okay to not be subscribed to that list
to post but make sure your mail program does not produce HTML-formatted
messages -- they will be rejected.  [1] contains more pointers on this.

1. https://gist.github.com/tfnico/4441562

-- 
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] no .git folder when creating new repository

[Konstantin Khomoutov]

On Fri, 5 Dec 2014 08:18:20 -
"Philip Oakley"  wrote:

> - Original Message - 
>   From: Aafaq Mateen 
>   To: git-users@googlegroups.com 
>   Sent: Thursday, December 04, 2014 3:22 PM
>   Subject: [git-users] no .git folder when creating new repository
> 
> 
>   Hi
>  I down loaded the Git Windows version 1.9.4 and gave my name and
> email at bash and  come back to Git GUI to create new repository.I
> cant see any .git folder in the newly created folder on my desktop.
> 
>   just wondering why its happening ..I tried couple of time
> uninstalling and stalling git back but its the same .
>   please help in this regard.
> Have you set your system to show 'hidden files and folders'?
> 
> Any file or folder (in windows) that begins with a dot is by default
> a hidden file/folder.

This is not correct: Windows does not have a convention of hiding
anything based on the names -- what it has, but only in one particular
piece of software -- Windows Explorer -- which is "the shell"
responsible, among other things, for browsing files, is hiding by
default the predefined set of "system" paths as well as hiding
extensions of files of "registered types" (my pet target for bashing
default settings on this class of OSes).  The reason the OP can't see
the ".git" subdirectory is Git explicitly setting the attribute "hidden"
on that directory after creating it; to demonstrate:

C:\tmp>git init foo
Initialized empty Git repository in C:/tmp/foo/.git/

C:\tmp>attrib foo\.git
H  C:\tmp\foo\.git

"H" here stands for "hidden". Run attr /? in the command prompt to see
what other attributes are supported on Windows filesystems (FATs, NTFS).

> *nix has a similar protocol.

Only in a sense: interactive command-line shells (like bash) and dumbed
down graphical shells like Nautilus indeed do not show "dotfiles" by
default, and command-line shells also by default exclude such files
from globbing operations, IIRC.  These files are not really hidden as
POSIX does not mandate implementing such a file attribute on
filesystems. So yes, they are hidden by policy only.

> In Windows Explorer you can set a preference to show them by default
> (see Google;-)

That is correct, yes.
My personal approach instead is to use a sensible file-browsing tool
for heavy-lifting operations leaving Windows Explorer for quick ad-hoc
tasks, and then it can be left mostly with default settings.
To name a few such tools, there are: FAR manager [1] (I admit it's
hardly popular anywhere except in the ex-USSR lands), Total Commander
[2] (proprietary), Free Commander [3] (Total Commander clone,
freeware), μCommander [4] (Java, for those with lots of free RAM, so
they've picked a classy name) etc.

[...]

1. http://www.farmanager.com/
2. http://www.ghisler.com/
3. http://www.freecommander.com
4. http://www.mucommander.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] git add doesn't display anything

[Konstantin Khomoutov]

On Fri, 12 Dec 2014 00:45:45 -0800 (PST)
scls  wrote:

> I'm new to Git so please excuse me if what I'm saying is wrong.
> I'm trying to move from SVN to GIT
> 
> I did $ git add filename
> but nothing appears.
> 
> I also try to add verbose flag (-v)
> but nothing else appears.
> 
> I think a message saying that ever this filename (these filenames)
> was ever added to repository
> or that this filename (these filenames) was just add to repository
> could be a good idea.

No, it wouldn't.
Git follow the usual convention of Unix tools which say nothing if the
operation had been carried out successfully.  This ensures easy
scripting among other things.
This might look alien to you, but this quickly becomes familiar: if the
tool worked, it did its job.

If you still want to double check (which is a good thing anyway to do
before committing), just run `git status` after `git add`.

-- 
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] Regarding reviewer for git

[Konstantin Khomoutov]

On Fri, 12 Dec 2014 04:03:19 -0800 (PST)
Priya K  wrote:

[...]
> We are looking for a reviewer to review the outline, scripts and
> video tutorials on *git* (version control system).  Reviewer should
> be either a faculty member of an institution/university or a person
> with 2-3 years of working experience in *git*.
> 
> A reasonable honorarium will be paid to the reviewer.
[...]

You might consider posting this to the main Git list (git at
vger.kernel.org) as well.  See [1] for more info.

1. https://gist.github.com/tfnico/4441562

-- 
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 add doesn't display anything

[Konstantin Khomoutov]

On Fri, 12 Dec 2014 18:24:34 +0100
"s.cel...@gmail.com"  wrote:

> I could expect verbose flag will made git become more verbose... but
> that's no so easy

Well, works for me:

~% cd /tmp
tmp% mkdir foo
tmp% cd foo
foo% git init
Initialized empty Git repository in /tmp/foo/.git/
foo% touch foo.txt
foo% git add -v foo.txt 
add 'foo.txt'
foo% git --version
git version 1.9.1
foo% 

-- 
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 add doesn't display anything

[Konstantin Khomoutov]

On Fri, 12 Dec 2014 21:51:09 +0100
"s.cel...@gmail.com"  wrote:

> $ git version
> git version 2.2.0
> 
> type again
> $ git add -v foo.txt
> no message will display
> 
> with verbose flag we could have a message similar to SVN
> 
> svn: warning: W150002: 'foo.txt' is already under version control
> svn: E29: Could not add all targets because some targets are
> already versioned
> svn: E29: Illegal target for the requested operation
> 
> I know Git is not SVN...
> 
> but displaying "warning: 'foo.txt' is already under version control"
> will be a good reminder
> 
> if I have 2 files foo.txt and bar.txt
> I first git add -v foo.txt
> then I need to git add -v bar.txt
> but I did a mistake and type again
> git add -v foo.txt
> git will give me an warning message
> so I could notice that I was wrong

Oh, I'm afraid you have gross misunderstanding of how Git works
(compared to Subversion).  In Subversion, "adding" a file means adding
it to version control -- that is, the file which was untracked becomes
tracked.  You then use `svn commit` to commit all the changes which are
there in the work tree or `svn commit fileA fileB ...` to only commit
changes in fileA, fileB etc.  Contrary to this, Git uses "staging"
approach to committing: when you run `git commit` (without the -a, -A
or -u command-line options), the commit is created from the so called
"staging area" (also known as "the index"); `git add fileA` adds --
"stages" -- *changes* present in the file fileA so that they will be a
part of the commit created the next time `git commit` is run.
Adding a file under version control is just a byproduct of adding the
file's changes to the staging area.  I mean, Git really does not have a
dedicated "add this file to version control" operation.  This means
a warning message like that in Subversion simply cannot exist in Git
as it does not have a concept to which that warning applies.

Now I can see why you don't see anything when attempting to `git add -v`
a file whose content did not change since the last `git add` had been
run for it:

~% git init /tmp/foo
Initialized empty Git repository in /tmp/foo/.git/
~% cd /tmp/foo
foo% touch foo.txt
foo% git add -v foo.txt
add 'foo.txt'
foo% echo bang >foo.txt
foo% git add -v foo.txt
add 'foo.txt'
foo% git add -v foo.txt
foo% 

As you can see, the `git add -v` command printed it "added" the file
two times out of three: the first time the file wasn't yet tracked, so
`git add` staged the file's contents (this obviously counts as a change
-- the size of the whole file), and the second time -- after the file's
contents changed.  The third time it printed nothing since the file's
contents did not change, and hence the command did nothing.

To recap, the meaning of `git add -v` mentioning the file in its output
means the file's contents had been staged.  If you wonder why this
might be at all useful, consider `git add`-ing a bunch of files using
either a wildcard, like '*', or just '.' meaning the current directory
-- in this case `git add` would only print the names of the files
it incorporated changes from, skipping the rest: ignored files and
files which did not changed compared to the staging area.

> I also would like to define git to display verbose message by default
> (without this -v flag)
> is there a config file for this ?

No idea.  Run `git help config` and try to search for the word
"verbose".  In any case you can use a git alias, like

  git config --add alias.vadd 'add -v'

and now you can do `git vadd file...`.

But before you do that...

I would strongly advise you to start with a good book on Git *before*
you will embark on using it in production: way too many people assume
that once they know some version control system, they know how version
control works.  This is wrong.  Git in many ways is radically different
from Subversion, and I'm not referring to to different meaning of the
same-named commands but rather differences in the underlying concepts
and approaches.  Hence I advise you to save yourself from possible
future pain in the neck and learn the Git's concepts and approaches up
front.

-- 
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] Hook for controlling owner, group, and permissions?

[Konstantin Khomoutov]

On Tue, 9 Dec 2014 10:32:28 -0800 (PST)
leam hall  wrote:

> Is there a HOWTO or tutorial for how to control owner, group, and 
> permissions on files as they get checked in? The ideal is that the
> owner and group change to "X" and "Y" and the permissions are set to
> 770. I'd like to figure out how to do and test that.

No way.  Git does not track permissions beyoud the executable bit; and
it also handles symlinks and submodules using the "file mode" field in
the trees it stores.  Owner user and group are not tracked at all.

The rationale for this is quite simple: all this stuff has no sense
outside of a particular developer's computer, and, Git is not a
deployment tool.

So what you can do about this.

1) Stop using Git for deployment and use a real deployment solution.

2) Maintain a script along with your code which is respolsible for
   traversing the checkout it's pointed at and setting correct ownership
   and permission bits.  Run it as a part of deployment sequence.

3) Devise a way to store metainformation on the ownership/permissions
   in Git itself along with the commits, at deployment site have a tool
   which is taught to extract this information and apply it to the
   checkout.  Exactly how to maintain this information, is up to you.
   This might be a special directory in the project tree, populated
   and included into a commit by a pre-commit hook, an annotated tag
   attached to a commit after it has been recorded, `git notes`
   and so on.

TL;DR
Git does not support recording ownership information and permission bits
on the files it maintains.  The reason is that Git is not an archival
tool.  So if you need this info, you have to maintain/apply it yourself.

-- 
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 2.X for Windows

[Konstantin Khomoutov]

On Sun, 14 Dec 2014 13:57:11 -0800 (PST)
TiborM  wrote:

> how it is with Git 2.x for windows?

It's in the works.

> Will it be release

Supposedly.

> and when?

No one knows.

[1] might give you a clear understanding of how vanilla Git and Git for
Windows relate, and why they have different schedules.

The things got more complicated since then as the folks working on GfW
decided to concentrate on reworking msysgit (the environment used
to develop GfW) to make it more modular and easy to use for those alre
ady familiar with MinGW/MSYS; more details at [2].  Note that the GfW
project is severely undermanned (not withstanding the fact the GfW
installer binary sustains several hundred downloads per day) so there's
absolutely no reason to go bitching about the delay on their support
forums -- they do whatever they are able to with the resources at hand.

In the meantime, you can read the wiki at [3] and build GfW 2.x
yourself.

1. https://groups.google.com/d/msg/git-users/lN2HkkYzYPA/-UJJtoBc-NIJ
2. https://groups.google.com/forum/#!topic/msysgit/xmAOOAZ9ing
3. https://msysgit.github.io

-- 
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] rolling back to the first commit in a repository

[Konstantin Khomoutov]

On Mon, 15 Dec 2014 08:46:46 +0200
Kevin Wilson  wrote:

> Is there a command to roll back to the first commit in a repository?

I think you need to think about what you want to achieve a bit harder:
to roll back what exactly?

All the commits in any Git repository form one or more (directed,
acyclic) graphs, and a commit is said to exist in a repository only if
it is referenced, directly or indirectly, by one of entry points to
those graphs.  Entry points are branches and tags, so to have a
repository with the single existing commit you have to make sure all
the branches and tags existing in that repository point to that single
commit.

If, instead, you wanted to reset just a single branch to contain just
that commit, you just do use `git reset` to make that branch point to
that commit.

Consider reading [1] to learn about how the `git reset` command works.

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

-- 
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] post-merge hook not working

[Konstantin Khomoutov]

On Thu, 11 Dec 2014 02:29:27 -0800 (PST)
Dharshan Bharathur  wrote:

> Hi all,
> 
> i enabled post-merge hook with following shell script
> #/usr/bin/env bash
> echo "==> following are changes made to local repo <=="
> 
> git fetch && git log ..origin/master --pretty=format:"%s - %ar by %an
> (%h)"
> 
> echo "===> ** <"
> 
> i have given needed permission also 
> chmod +x post-merge
> 
> when i do 
> git pull origin master
> 
> it prints me 
> echo "==> following are changes made to local repo <=="
> echo "===> ** <"
> 
> 
> But when i run the same 
> git fetch && git log ..origin/master --pretty=format:"%s - %ar by %an
> (%h)" command it will return me exact result what i expect. 
> 
> 
> Does any one suggest me where i an going wrong.?

Supposedly git, when run from your hook, sees different environment or
working directory or whatever.  Consider tracing what happens: in your
script, before the line calling out to Git, put

  exec 2>&1
  export GIT_TRACE=1

and then see what will be printed by the hook.

-- 
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] rolling back to the first commit in a repository

[Konstantin Khomoutov]

On Mon, 15 Dec 2014 09:50:31 -0500
wor...@alum.mit.edu (Dale R. Worley) wrote:

[...]
> As far as I know, there is no syntax to identify the oldest commit on
> the current branch.  But 
> 
> git log --pretty=tformat:"%h %ai %s"
> 
> will list all the commits that are part of the current branch, and
> from those you can select the hash of the oldest one.

  git log --reverse

should help.

Unfortunately,

  git log -r -1

lists the last (HEAD) commit contrary to what I would naturally expect.
I do understand the reason why it works as it does but oh well... ;-)

-- 
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] Upgrading git from version 1.7.12.4 to 2.2.0 on Centos 6.5

[Konstantin Khomoutov]

On Mon, 15 Dec 2014 12:43:44 -0800 (PST)
Ashish Yadav  wrote:

> I would like to upgrade my current git from version 1.7.12.4 to 2.2.0
> on Centos 6.5. 
>
> Can I upgrade directly to 2.2.0 or or do I need an intermediate
> version to upgrade to first?

AFAIK, Git's object store format did not change, so no, you do not need
intermediate versions, but if you want to be sure, read the release
notes of intermediate releases -- they are freely available.

> Are there any gotchyas that I need to look out for when upgrading?

2.0 was a major version, so it did in fact change some defaults.
IIRC, it should only affect "local" (as opposed to "server-side") repos
though, but read the release notes.

> If needed, how can I rollback?

Install the 1.7.12.4 package back.
If you will detect any problems with the repos, you'll restore them
back from the nearest backup to the pre-upgrade state.

> What are the implication of upgrading git on the linux server? Is it 
> transparent to the application and end user?

Should be.  Contrary to some other notable DVCS systems, Git strives to
maintain backwards compatibility in its network protocol and object
store format as much as possible.  But if you're unsure, the things to
do are very simple:

* Read the release notes;
* Set up a test box (virtualization is very cheap these days), upgrade
  Git there, test how the older clients work with it, test how it
  works with the existing (1.7.x) repo.

-- 
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] Just downloaded my first repo

[Konstantin Khomoutov]

On Thu, 18 Dec 2014 04:25:14 -0800 (PST)
McDouglas Perez  wrote:

> I downloaded my first repo. The name of the directory is 'template'
> how to open this directory in git?

Git comes as a set of command-line tools.  Those tools which are
supposed to access an existing Git repository (no matter -- if you have
created it yourself or `git clone` did this for you) start with the
current directory, in which they were run, and try to locate a special
directory containing the repository's data (it's named ".git", and is
typically hidden).  If they fail to locate this directory, they go one
step above and look there, if they fail again, they repeat this step
until they hit the root of the file system.  This way, the tools make
it possible to run them in any subdirectory of the project maintained
in Git.

So... Open a command-line prompt, change current directory to the
directory resulting from running `git clone` you did and run

  git status

there.  If it prints out a summary message about your repo, all is well.

Well, OK.  Please take no offence, but I must say your question give
away your near-zero knowledge of Git, and hence whatever I wrote above
might make almost no sense to you.  If yes, please please please start
with a book on Git [1].

On the other hand, if you're familiar with Git, just the wording of the
question did not make me get it, and you really meant some GUI app to
work with a Git repo, then there are plenty of them -- just google.
For Windows, I'd recommend "Git Extensions" [2].  But I should warn you
that while working with Git is not hard, the concepts it's based on are
rather complex for uninitiated, so if you hope a GUI app will make
working with Git a walk in the park, I assure you it won't -- sooner or
later you will be bitten by lacking basic knowledge.  So, again, please
start with a book.

1. http://git-scm.com/documentation/
2. https://code.google.com/p/gitextensions/

-- 
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] Debian7.7 ssl sertificate problem

[Konstantin Khomoutov]

On Sat, 27 Dec 2014 13:44:14 -0800 (PST)
Z Morar  wrote:

> After two months of use without any problem, now I can't push my 
> developer-work over git to bitbucket server. The error message ssl 
> sertificate.. etc. How to solve this problem?
> Thank you very much
> 
> p.s. Debian 7.7 32 bit 

Sorry but this does not look like a project description.
Is it really that hard to just copy the entire error message and paste
it here?  I think definitely not.

In either case, if the error is about Git not trusting the remote
certificate for some reason, you might skip this check by making Git
see the environment variable GIT_SSL_NO_VERIFY.

For instance, do

  $ export GIT_SSL_NO_VERIFY=1
  $ git push blah blah ...

or just

  $ GIT_SSL_NO_VERIFY=1 git push blah blah ...

and that should do the trick.

The proper way to deal with this error is to fix the problem rather
working around it.  The first thing to check is to verify you have the
ca-certificates package installed and updated.

Anyway, without the detailed problem description it's all plain
guesseneering.

-- 
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] gitk recent msysgit build no longer shows full tag text. Instead it shows '2 tags' or 'n tags'

[Konstantin Khomoutov]

On Tue, 20 Jan 2015 01:27:52 -0800 (PST)
gary lucas  wrote:

Hi!

> See attachment.
> 
> I updated recently and this behaviour is driving me crazy, our CI 
> environment tags our builds and it's hard to see at a glance in gitk
> what happened where.
> 
> $ git version
> git version 1.9.5.msysgit.0
> 
> Is there a way to set this back to the prior default of not
> collapsing the tags down into something useless?

In [1], I have already gave you full explanation of your issue and
advised you to contact the main Git list (on which the Git development
happens and is being discussed).  What point is re-posting this same
question on another user-support forum, and without even providing any
link to the prior discussion?

1. https://groups.google.com/d/topic/msysgit/0dtZ1Ax5B3o/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] Tag dependency on Submodules in a project

[Konstantin Khomoutov]

On Fri, 6 Feb 2015 07:46:00 -0800 (PST)
Wilson Ren  wrote:

> Is there a way to keep track/update which submodule commits used in a 
> project? 
> 
> From what I have read and tried, the sub module is pointed at the
> commit it has in its HEAD when it's first time added in the main
> project. If we fetch a (new) different commit of 
> the submodule to the main project, no change is made to the submodule 
> reference. 
> 
> Is there any workaround?

Git tracks submodules using exact commits (see [1]), so, if I
understood your fears correctly, they are unfounded: when you check out
any prior state of a superproject, the checkout will refer to the exact
states of all its submodules recorded in that superproject's commit.

1. http://git-scm.com/book/en/v2/Git-Tools-Submodules

-- 
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] Copyright on wildmatch.c

[Konstantin Khomoutov]

On Tue, 24 Feb 2015 09:02:21 +0100
Guilherme  wrote:

[...]
> The problems at hand is that I'd like to use wildmatch.c and some
> dependencies (hex.c, some portions of compat-util.h) but it seems that
> git is GPL whereas tss is Apache2 licensed.
> 
> Is there any possibility to re-license the files above to Apache2 for
> the TSS project?
[...]

This is a wrong mailing list to ask such a question: here, we deal with
problems end-users have with Git, and this list has nothing to do with
development of Git and its source code licensing.
You should direct this question to the main Git mailing list, which is
 (see [1] for more info).

Note that you might need to solicit explicit permission for relicensing
from all who contributed to those files.  On the other hand, when a
quesion arose a couple of years ago about using bits of Git string
manipulation library somewhere, the response of the devs I've seen on
the list was positive so your chances are high IMO.

1. https://gist.github.com/tfnico/4441562

-- 
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 use git to store large files without keeping track of versions?

[Konstantin Khomoutov]

On Sun, 22 Feb 2015 07:51:59 -0800 (PST)
pengyu...@gmail.com wrote:

> I have some data files that need to be stored along with source code.
> These data files are large, but I don't need to keep their versions.
> I only need to keep the versions of the source code.
> 
> git-annex is mainly for large files with versioning. Therefore, it is
> not suitable for my situation.
> 
> Does anybody know whether there is a way to use git to manage source
> code (with versioning) as well data files (without versioning)?

It's a bit unclear what you are really asking for.

Are you fine with keeping those files checked into your repository and
are just afraid each commit will somehow include those file into the
repository again and again (many guides state that with each commit Git
stores snapshots, not deltas)?  If so, then fear not: while Git indeed
stores snapshots, the content which did not change will not be
somehow included again -- the new commit will reference existing
objects representing those big files.  So, just add and commit these
files once and just make sure you don't change them and commit these
changes.

If this is not what you want, I can think of two more possibilities:

* You want these files in the repo but don't want them to be checked
  out by default.

* You do not want these files even in the repo.

Which one do you want?

The first case is made possible by a simple fact Git is able to store
any object in its database -- when you do this, the contents of the
object, named "blob" in Git's parlance, will persist in the repository
as long as there's something referencing it (let's not dig into
nitty-gritty details of this for now).  So a common idiom is to put an
object into the repository and then make a tag (usually annotated)
pointing to it:

  $ git tag -a my-big-file $(git hash-object -w my-big-file)

The `git hash-object -w` command will read the specified file, put it
into the repo and print the SHA-1 hash calculated over its contents.
The `git tag -a` command then creates a tag (named "my-big-file")
pointing to that hash.

The upside of this approach is that it's simple and elegant: you have
the file in the repo, and when you want its contents, you simply
extract it to produce whatever file you want:

  $ git cat-file my-big-file^{} >/some/path/to/my-big-file

The downsides:
* The data is in the repo.
* If you have lots of files, "getting them out" of the repository
  is tedious or requires scripting.

The second case is the most vague: if you want certain Git files to be
kept out of the repo, then Git is not the tool to manage them.
Not directly at least.  Basically, commit a file into your repo which
contains explanations of how to make these files available at the place
where your repo is checked out.

If you still want these files managed by Git, put them all in a
separate repo, and add it as a submodule to the main repository.
If you will so wish, you'll be able to check out the main repo without
the submodules so the big files will still technicaly be out of it
while still kept in Git.

git-annex is an interesting possibility as well but I'm afraid it's a
standalone tool, that is, it does not really integrate into "regular"
Git workflow (like Git sumbodules do).  But I'm not familiar with this
tool so can't really comment on this.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Newbie in Git

[Konstantin Khomoutov]

On Tue, 3 Mar 2015 06:50:45 -0800 (PST)
Prudhvee Narasimha Sadha  wrote:

What is your intent when you call

  git -C '' cmd

?  I mean, what this command is supposed to do?
Please describe this as precise as possible.

-- 
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 workflow with MySQL scripts

[Konstantin Khomoutov]

On Tue, 3 Mar 2015 07:17:31 -0800 (PST)
Michael Sheaver  wrote:

> I am using MySQL on my local Windows laptop to compile data and
> produce reports for my enterprise related to PIV issuance.
[...]
> The challenge that I have is that although all of these scripts
> loosely relate to the PIV project, but pretty much stand on their own
> for each function. I would like to be able to use tags to monitor
> version numbers for each of the scripts ( 1.0, 1.1, 1.2, 2.0, and so
> on). In order to do this, do I need to create a separate repository
> for each script? If so, that would seem to be a lot of extra work. 
> 
> Can anyone suggest a workflow that will help me to monitor and track 
> version numbers for each script separately?

I would keep things as simple as possible and just do this:

1) Turn your folder into a Git repo (`git init .`).
2) Add all your scripts into it and record the first commit;
   mention current version of each script in the extended part of the
   commit message.

When a new version of a particular script appears, update the
appropriate file in your folder to match it, `git add` that script file
solely and record a new commit.

You will then be able to see the history of changes of a particular
script file by using

  git log -- scriptFileName.sql

There is no tags in my simplistic picture, but I'd just record version
of the script file recorded in a commit using its version number in the
commit message -- you will see them in the `git log` output and will be
able to use git-log's search facilities to search for a particular
version (present in the commit message).

You can still use tags with this approach -- just devise proper
"namespacing" for your tag -- for instance, put the base name of a
script file (without the extension) into tags related to that script
file, and then tag each commit recording a new version of that file
with such a tag -- say, if you've just recorded version 3.2 of
mumboJumbo.sql, tag it using "mumboJumbo-v3.5".


If you feel extravagant, you can even not use branches at all, just
shovel new versions of your script files into the repo using the
standard if lesser known

  git hash-object -w myScript.sql

and then tag whatever SHA-1 hash it printed out using the naming scheme
outlined above.  You will then only have tagged blobs and no history at
all (it will be implicitly encoded in the tag names).

I'd still prefer a single branch and may be tags on its commits.

> I have posted this same question on 
> StackOverflow:
> http://stackoverflow.com/questions/28833957/git-workflow-with-mysql-scripts

Thanks for mentioning -- this level of netiquette is rare these days ;-)

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

[Konstantin Khomoutov]

On Mon, 16 Mar 2015 19:07:16 +0530
Rustom Mody  wrote:

[...]
> Finally I added a dummy-file to downloads; add-commited it and then
> ignored downloads.
> 
> Seems convoluted and unsure (to me).
> Is there a better way?

No, there isn't.  Git does not track directories directly -- only as a
byproduct of adding files contained in them.  So either do what you did
or, possibly better, add a script to your repository which, when
called, will create this directory locally.  The reasoning behind this:
Git is not a deployment/configuration system but rather a content
management solution with "content" being defined as whatever is
contained in the files being managed.  From this PoV, having an ability
to put a sole directory under version control has no sense as it does
not represent content but rather a workplace configuration orthogonal
to the repository's content.

-- 
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 command/plugin to create archive to send it for the code review

[Konstantin Khomoutov]

On Wed, 11 Mar 2015 04:54:36 -0700 (PDT)
Raluca Popa  wrote:

> Is there a plugin to integrate with GIT in order to have the chance
> to create an archive with the local changes?
> 
> For instance I want to create an archive (zip/jar - I am coding in
> Java) with the files I changed in order to send them via e-mail to a
> technical team lead. That team lead will download the archive I sent
> and create using a command line/user interface command, just to
> create my own local changes on his local machine.
[...]

I think you're missing proper code review tools which might be
full-profile (like Gerrit) or low-profile (like just mailing your
changes as a patch or a patchset) so I'd first ponder a possibility of
implementing such a proper code review.

If you still insist on doing it the way you outlined, this solution can
be easily scripted in whatever programming language you're comfortable
with -- around the `git show --num-status` or `git show --raw` commands:
these return a list of files "touched" by the most recent commit, so in
your script you could read the names of those files and then run any
archival tool to prepare an archive you need.
Note that if you want to include the files touched not only by the most
recent commit but by a range of commits, you'll need to use `git diff`
with the names of the first and last commits.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git remote only features one of the two branches it's supposed to have...

[Konstantin Khomoutov]

On Sun, 22 Mar 2015 16:20:24 -0700 (PDT)
Xtian Simon  wrote:

[...]
> 4) Next I pushed to origin (site.git) to make sure I have the latest
> and greatest of both Live and Test:
>   `test$ git push -u origin test`
>   `live$ git push -u orign live`
> 
> 5) I updated the server info
>   $git update-server-info
> 
> 6) Cloned from remote to local
>   $ git clone http://mysite.com/dir/to/site.git
>   => Viola! Now I have site/ 
> 
> I'm expecting to get a Repo with both Test, Live branches. 
> But I'm only getting one branch (master) and it's the live branch.
> 
> What did I do wrong in this setup?

Does running the command

  $ git branch -a

shows you both "test" and "live" branches?
They will supposedly be presented as "remote/origin/test" and
"remote/origin/live", and will be painted in red if you have colors
available/enabled on your terminal and default coloring settings.

If yes, then you have merely fell victim of a common misunderstanding
of how local and remote branches relate to each other in Git.
I've tried to explain these differences in depth at [1] so you're
welcome to read it.  A classic (and more accessible if as well more
dumbed-down) explanation is at [2].

1. https://groups.google.com/d/msg/git-users/mJ0iOIZO8ak/M5WpwNix2lkJ
2. http://git-scm.com/book/en/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] Git conflict issue

[Konstantin Khomoutov]

On Mon, 23 Mar 2015 17:47:47 -0700 (PDT)
 wrote:

[...]
> Remote "sample.txt" has been chanaged bellow,
> ---sample.txt@remote---
> line1:
> line2:
> line3:SERVER
> line4:
> line5:
> ---(EOF)---
> 
> Local "sample.txt" has been changed like bellow,
> ---sample.txt@remote---
> line1:
> line2:
> line3:CLIENT
> line4:CLIENT
> line5:
> ---(EOF)---
> 
> At first, I pushed "smaple.txt@remote" to remote repository
> Next, I fetched origin and merged FETCH_HEAD.
> 
> Then, conflict occured like this...
> ---conflict---
> line1:
> line2:
> <<< HEAD
> line3:CLIENT
> line4:CLIENT
> ===
> line3:SERVER
> line4:
> >>> FETCH_HEAD
> line5:
> ---(EOF)---
> 
> I think line4 is not conflicted, but merge result shows conflict at
> line3 and line4.
> 
> I want to get the merge result like following.
> ---conflict---
> line1:
> line2:
> <<< HEAD
> line3:CLIENT
> ===
> line3:SERVER
> >>> FETCH_HEAD
> line4:CLIENT
> line5:
> ---(EOF)---
> 
> Is it configuration problem?
> 
> [Remote bare repository]git version 1.7.1 on CentoOS6.6
> [Local repository]git version 1.9.4.msysgit.2 on Windows7

You're merging

line1:
line2:
line3:SERVER
line4:
line5:

into

line1:
line2:
line3:CLIENT
line4:CLIENT
line5:

Merging means reconciling changes both "sides" of the merge have to
produce the contents which, logically, includes the changes made by all
the sides in a way such that the result "takes into account" what both
sides contribute to the result.

IIUC, you seem to imply that since line4 has been changed only on the
one side, there should be no conflict.  For a simple merge between two
commits which share common history, Git uses the tree-way merge -- that
is, it considers not only the states the content being merged has at
both sides of the merge but their nearest common ancestor commit as
well.  I have recreated your situation (using only local branches, but
that should not matter), then extracted all the three versions of the
file -- "theirs", "ours" and "common ancestor" -- and run GNU `diff3 -m`
on them, and got the same result: line4 is considered changed as well.

So, I'm not sure where to go from there.  I seem to understand your
reasoning, but while it certainly had a valid grain in it I'm not sure
it's universally correct.  Let me explain: suppose these are not mere
abstract "lines" but rather the code of some imperative program.
To start with, when you merge, typically it's assumed that both sides
maintain their content in a "correct" state (yeah, in a philosophical
sense): say, the program as the "theirs" side have it is correct and the
program as the "ours" side has it is correct as well -- even though
they differ.  Now suppose that we apply your reasoning to the detection
of conflicts when merging and do not mark "ours-only" change at line4
as conflicting.  The problem there is that the code on the lines before
line4 in "theirs" program might rely on line4 being in the exact state
it is!  Your approach to merging would "silently sneak" a change
breaking the "theirs" state of the program steering your focus away
from that fact because the conflict would be elsewhere in the file.

Hence I'm inclined to deem this case as "working as intended" even
though the result appears somewhat counter-intuitive for this particular
case.

-- 
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 svn remote add/set-url, please?

[Konstantin Khomoutov]

On Fri, 27 Mar 2015 09:00:47 -0700 (PDT)
Andrew Pennebaker  wrote:

> Could git-svn please include a remote add / set-url command, so that
[...]

Hi!

Unfortunately, this list has nothing to do with adding features to Git
-- only to helping users deal with problems they have when using Git.

Please consult [1] for further information on where to ask your
question.

1. https://gist.github.com/tfnico/4441562

-- 
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 can I unregister Git VCS root?

[Konstantin Khomoutov]

On Sun, 29 Mar 2015 01:23:16 -0700 (PDT)
Natalija Yakovleva  wrote:

> I would like to use java project from GitHub. I'd like to write and
> compile it using Idea Community Edition 14.0, on my machine, and to
> perform Pull/Push etc to Git. To synchronize the project with Git, I
> have performed the following steps:
> 
>- Idea - VCS -> Checkout from version control - GitHub (master
> branch was downloaded)
>- Idea - project_name -> Git -> Repository -> Branches ->
> my_branch_name -> Checkout as new local branch
> 
> After these actions it was possible to work with java classes in 
> my_branch_name project. But after some time the following message
> appeared: "The directory my_branch_name is under Git, but is not
> registered in the Settings". I have clicked "Add root" :) . And now I
> can not add new java classes, do not see one public class from the
> another, can not run main procedure - there is message "Process
> finished with exit code 1" (but it was run successfully before).
> 
> I understand that I have added some new root? How can I fix it now?
> Please help, thanks in advance 

Sorry, but this list deals with Git, that is, the `git` command you
usually call from the command line plus its standard "extensions" like
stock GUI clients (`git gui` and `gitk`) Subversion shim and so on.
Your problem has nothing to do with Git per se as it's about the way
IDEA IDE works with Git.  While it might just call plain git binary,
Git itself has no concept called "root"; you can't "add roots" in a Git
repository -- there's simply no such word in a Git vocabulary.

Hence I'm afraid we're unlikely to be able to help you with this
problem.  Please try asking on IDEA IDE support channels instead.
[1] looks like a good candidate.

1. https://devnet.jetbrains.com/community/idea/ideacommunity?view=discussions

-- 
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] Cannot access branches on my bare.git repo

[Konstantin Khomoutov]

On Mon, 30 Mar 2015 08:59:47 -0700 (PDT)
Frank Gutierrez  wrote:

[...]
> git ls-remote origin 
> 
> dcca23413a0e94660cd2073c7b75e09b14923dd9 refs/heads/project1
> 
> *(only one project/branch shown)*
> 
> 
> 
> *My bare.git repo does have files under the refs subdirectory:*
> 
> refs
> ├── heads
> │   ├── feature
> │   │   ├── project1
> │   │   └── project2
> ...
> ...
> *(30+ projects/branches in a list)*

What happens if you do

  cd ~/path/to/bare.git
  git branch -a

?

Does it list all your 30+ branches?
I mean, check the bare repository itself: many Git commands work in bare
repos just like they do in normal repos.

I also recommend you to run

  GIT_TRACE=1 git ls-remote origin

to double-check what Git actually calls looks sensible.

-- 
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: Cannot access branches on my bare.git repo

[Konstantin Khomoutov]

On Mon, 30 Mar 2015 09:54:05 -0700 (PDT)
Frank Gutierrez  wrote:

> *UPDATE*
> 
> *refs/heads files do _not_ point to objects*
> 
> path: objects/78/803b535
> path: objects/4c/c30382a
> path: objects/b9/9cd833e
> path: objects/4a/a4629d6
> path: objects/58/8734ab5
> path: objects/57/7ffcd9c
> ...
> ...
> 
> 
> I checked the paths and they are not in the objects subdirectory

The objects need not necessarily be files under the objects/ directory:
for efficient storage, Git only allows a moderate number of objects be
stored this way; most objects get compressed into the so-called "pack
files".  The objects stored "as is" are called "loose".  So your
branches need not necessarily point to loose objects, and they might
legitimately point to objects stored in one of the pack files.

To verify the repository's integrity, you might want to run the

  git fsck

command on it.

> I'm thinking a rebase might be the culprit 
> 
> But how to fix???

While I think this your problem is a non-issue (as explained above), if
you're afraid of rebased branches being force-pushed to your bare repo
by mistake, consider enabling the reflog in that bare repo (reflog is
disabled by default when a bare repo is initialized).  You can do this
by running the

  git config --local --add core.logAllRefUpdates true

in your bare repository.

As a result, all "drastic" movements of heads in this repository will
be logged as they do in "normal" repositories, and their original
positions could be recovered.  Note that in exchange you get
potentially more disk space wasting in your 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] GitHub ingored file

[Konstantin Khomoutov]

On Mon, 30 Mar 2015 11:13:52 -0700 (PDT)
Marko Zivanovic  wrote:

> is there any way how track again file which is in ignore list
> currently.

Sure!

[...]
> Is this possible? I am newbee but google ing of this problem did not
> lead to soluition.
> every help is welcome

Please run

  git help add

(which should open a manual page describing the `git add` command for
you) and search there for the word "ignore".  The solution is among the
first 4-5 paragraphs of text there.

If you don't know where/how to run `git help add`, google for the
three words: "man git add" (without the quotes) and proceed with the
first link presented.

-- 
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: Cannot access branches on my bare.git repo

[Konstantin Khomoutov]

On Mon, 30 Mar 2015 11:24:16 -0700 (PDT)
Frank Gutierrez  wrote:

> *Git commands run from bare.git*
> 
> $ git branch -a 
>   reactive-gallery

...and what happens if you do this in a repo restored from a backup?

-- 
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: Cannot access branches on my bare.git repo

[Konstantin Khomoutov]

On Mon, 30 Mar 2015 12:12:01 -0700 (PDT)
Frank Gutierrez  wrote:

> *My backup.git repo looks bad.*
> 
> git br 
> 
> git br -a
> 
> both show nothing.

Then I'm afraid someone did delete all the branches in the bare
repository.  If `git fsck` shows OK in it, it's supposedly OK, and the
problem of the missing branches is elsewhere.

On the other hand, in your original post you've said you have a bunch
of seemingly valid entries under refs/heads in your bare repo.
If so, I don't know why `git branch -a` shows nothing about them and
not fails with an error at the same time.

I'd start with extracting SHA-1 names of the target commit objects from
those files under refs/heads and grepping the Git object database for
them, like this:

  cd ~/path/to/bare/repo.git
  find refs/heads/ -type f -print \
| while read f; do cat $f; done >/tmp/names
  git rev-list --objects --all | grep -Fw -f /tmp/names

If the last command will output more than a single entry¹, this means
you still do have commit objects of your "lost" branches in your object
store, and you can easily "regain" them by, say, sticking tags onto
those SHA-1 names and then studying the commit logs leading to each
resulting tag.

¹ You showed that Git itself reports there's a single branch, so you
  ought to see its commit object in the output 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] Second user defined filter on add or checkout

[Konstantin Khomoutov]

On Thu, 2 Apr 2015 03:21:05 -0700 (PDT)
Uwe Bieling  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] git status shows different status for local and remote drive

[Konstantin Khomoutov]

On Sun, 5 Apr 2015 15:21:36 -0700 (PDT)
Andres Suarez  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 ..." to update what will be committed)
>   (use "git checkout -- ..." 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 ..." 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

[Konstantin Khomoutov]

On Wed, 8 Apr 2015 10:59:42 -0700 (PDT)
win-newbie  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] Git openssl version

[Konstantin Khomoutov]

On Wed, 8 Apr 2015 11:30:11 -0700 (PDT)
win-newbie  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] Re: Git openssl version

[Konstantin Khomoutov]

On Wed, 8 Apr 2015 13:24:35 -0700 (PDT)
win-newbie  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] GIT for large binary files and file size limit?

[Konstantin Khomoutov]

On Tue, 14 Apr 2015 09:21:52 +0200
Magnus Therning  wrote:

> On 14 April 2015 at 08:44, Ushaswarna Kiranmayi
>  wrote:
> > I wanted to know if Git supports large binary files of Gigabyte/
> > terabytes size. What is the cost of using GIT by approximately 10
> > (this would certainly increase to large number later)users?
> 
> Git is first and foremost a version control system for text files
> (source code).  While it *can* handle binary files it's not its forte.
> For such large binary files I'd certainly look for alternatives.

The alternatives are: git-annex, git-fat, git-media and the recently
announced git-lfs.  git-annex is arguably the most battle-tested among
these while git-lfs claims to make large externally stored files
transparent to the main workflow.  I did not try either of these
solutions myself, so cannot really judge.

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

[Konstantin Khomoutov]

On Tue, 14 Apr 2015 03:43:12 -0700 (PDT)
rajiv gupta  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] upgrade gitolite

[Konstantin Khomoutov]

On Tue, 14 Apr 2015 23:54:40 -0700 (PDT)
Syaifull Al-Bandary  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] Error when building subversion

[Konstantin Khomoutov]

On Wed, 15 Apr 2015 09:08:17 -0700 (PDT)
win-newbie  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] how to --since and --until get the expected git log

[Konstantin Khomoutov]

On Mon, 20 Apr 2015 15:37:22 +0800
lei yang  wrote:

> lyang001@lyang001-OptiPlex-9010:~/stats/gitstats$ git log
> --pretty=format:'%ad %an' --date=short --since='2013-1-25'
> --until='2013-11-03'
> 2013-09-22 Alexander Strasser
> 2013-07-29 Heikki Hokkanen
> 2012-12-16 Andrey Devyatkin
> 2013-07-26 Heikki Hokkanen
> 2013-07-23 Heikki Hokkanen
> 2013-07-23 Stephen Gordon
> 2012-08-26 Sven van Haastregt-> this is not what I
> wanted 2013-02-24 Heikki Hokkanen
> 2013-02-24 Heikki Hokkanen
> 2013-01-28 Ernesto Jiménez
> 
> But I want to get the time only between '2013-1-25'  and
> '2013-11-03', Is there a general way to remove them since I have may
> of this kind of unexpected results

--since and --until check their arguments against "commit date" while
the format string you're passing to --pretty displays the "author date".
These two are different, because a commit might have both the author
and committer.  In the supposedly most common case, when you run
`git commit` in your local repository to to commit the changes you've
prepared and staged manually, the committer and the author are the
same, and the dates are the same, too.  But they do not have to be the
same: the classic case when they're not is applying a patch / patch
series prepared by, say, `git format-patch`.  Cherry-picking is another
example.  In these cases, the author is whoever actually provided the
piece of code (authored it) and the committer is whoever applied
(integrated) the work of the author.

I'd recommend you to get the SHA-1 name of that commit (add %h to your
format string) and then run `git show` on that name to see what are the
headers in that 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] Re: unable to reset working copy changes

[Konstantin Khomoutov]

On Sun, 19 Apr 2015 15:04:26 -0700 (PDT)
Thomas Ferris Nicolaisen  wrote:

> > Hi, I am unable to reset my working copy changes.
> >
> > I have two files in this project which differ only in their case:
> >  listwise/liblistwise/op/c/c.c
> >  listwise/lblistwise/op/C/C.c
> >
> > It appears that git is being confused by the similar file names.
> >
> > Is this a bug?
> >
> > todd@HOSSBEAST /q/Code/fab (master)
> > $ git version
> > git version 1.9.5.msysgit.1
> >
> I'm assuming you're on Windows since  you use a Git built with
> msysgit.
> 
> Windows does not have a case-sensitive file-system.

Nit-picking a bit, NTFS is case-preserving but case-insensitive.
That is, given the right tools, it is actually possible to rename "foo"
to "fOO", and the name will be stored as "fOO" (no case conversion is
done).  But yes, when matching a file name against the entries
of the directory it's located in, NTFS performs case-insensitive
comparison.

AFAIK, HFS on Mac OS X exhibits the same behaviour.

[...]
> If you are in control of this repository, I would heavily recommend 
> changing some naming conventions. Having multiple files with the same
> name is asking for trouble and confusion.

Absolutely!

-- 
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 stash merge

[Konstantin Khomoutov]

On Mon, 20 Apr 2015 09:24:39 -0700 (PDT)
Pawel Por  wrote:

> I've just upgraded the linux kernel git source tree and I want to
> "pop" my stashed work. I do the following:
> git stash pop
> 
> and I got the following message:
> mm/Makefile: needs merge
> unable to refresh index
> 
> I also tried:
> git stash pop --index
> 
> How can I overcome this obstacle.
> I did "git stash" before "git pull".

Well, IMO `git stash pop` merely told you it detected a conflict
when trying to apply what you've stashed.  Your work tree is now in
conflicting state, and the stash wasn't dropped.  All you have to do is
resolve the conflict by editing mm/Makefile and `git add`-ing it to the
index.  Use `git status` + `git diff` to verify your changes from the
stash entry actually landed into the work tree.

If you feel uneasy about "merging" the stashed change, create a branch
out of it (`git stash branch`) and merge those changes by merging the
new branch.

-- 
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: There may be a mistake in book Pro Git about rebase

[Konstantin Khomoutov]

On Tue, 21 Apr 2015 06:08:46 -0700 (PDT)
Thomas Ferris Nicolaisen  wrote:

[...]
> Your understanding is correct, but I don't think your sentence reads
> so well. I agree with you that the sentence in the book does not
> sound optimal either. Here's what I would write:
> 
> Original:
> 
> > This basically says, “Check out the client branch, figure out the
> > patches from the common ancestor of the client and server branches,
> > and then replay them onto master.” 
> 
> 
> Suggestion:
> 
> > This basically says, “Take the client branch, figure out the
> > patches since it diverged from the master branch, and replay these
> > patches in the client branch as if it was based directly off the
> > master branch instead". In other words: transplant the client
> > branch to be based off the master branch instead of server.

I like your version much better!

By the way, in the hope to be useful to the OP, here's my attempt to
explain to someone the difference between cherry-picking and rebasing
[1] which extensively touches on how rebasing "replays" commits on a
branch which that branch has "on top" of where it's being rebased onto.
It uses the pictures from the book being discussed. ;-)

1. http://stackoverflow.com/a/11837630/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] g...@vger.kernel.org Fails

[Konstantin Khomoutov]

On Tue, 21 Apr 2015 08:36:11 -0700 (PDT)
a...@mojotech.com wrote:

> I can't send an email to the bug email address. It fails from two
> different email addresses, regardless of content, with this message:
[...]

> The error that the other server returned was:
> 550 5.7.1 Content-Policy reject msg: The message contains HTML
> subpart,

^^^ This one.  The Git mailing list accepts only plain text messages.
Even multipart/alternative messages containing both plain text and HTML
parts containing the same text (semantically) are not accepted.

It appears, that the gmail web interface does this, unfortunately.

Please try sending your mail from a simple no-frills mail client and
make sure you have HTML crap turned off in its settings (if it has
these).  Namely, Thunderbird uses HTML by default.

-- 
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] g...@vger.kernel.org Fails

[Konstantin Khomoutov]

On Tue, 21 Apr 2015 09:30:00 -0700 (PDT)
a...@mojotech.com wrote:

> > ^^^ This one.  The Git mailing list accepts only plain text
> > messages. Even multipart/alternative messages containing both plain
> > text and HTML parts containing the same text (semantically) are not
> > accepted. 
> >
> > It appears, that the gmail web interface does this, unfortunately. 
> >
> > Please try sending your mail from a simple no-frills mail client
> > and make sure you have HTML crap turned off in its settings (if it
> > has these).  Namely, Thunderbird uses HTML by default. 
> >
> Thanks! Could you suggest one? I used to use Pine on Telnet back in
> the day, but that was pre Gmail.

Personally, I'm using Sylpheed but Thunderbird would do as well.
Thunderbird defaults to producing HTML, but this can be turned off --
either completely or for the current message only.  Sylpheed defaults
to plain text.

>From quick googling it turns out that Evolution can't be set to not
attach junk HTML, and Outlook, of course, exhibits the same behaviour.

Not sure about other popular software packages.

-- 
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: Getting the list of files which are changed

[Konstantin Khomoutov]

On Tue, 21 Apr 2015 21:07:52 -0700 (PDT)
Tanveer Malik  wrote:

> Ahh sorry, if I was not very clear in my question. What actually I am 
> looking for is a way to get the working copies of the files different
> from its parent branch e.g., I create a branch 'develop' from
> 'master', then work on files say style.css and on another file called
> abc.php. Now I want a way to get only these two files [style.css,
> abc.php] in the working directory.

`git show` does that.

For instance, you're working on "develop" but would like to get the
contents of a file "main.css" as it's currently on "master".
If so, you'd use

  git show master:main.css

to get the contents of "main.css" on "master" printed.

If you want to actually save it somewhere (it seems, you do), redirect
the output:

  git show master:main.css > whatever.css

If you redirect the output to "main.css" as well, its content will be
overwritten with the contents of "main.css" on "master" -- effectively
as if you've checked out that single file from "master".

Consequently, `git checkout` can do that as well ;-)
To replace the contents of a checked out file with its contents in
another revision, do

  git checkout...

for instance, you could do

  git chekcout master main.css


Please note that all these examples assume the file named "main.css" is
in the root directory of the repository (and the work tree), that is,
at the top level.  If it's in a subdirectory (or deeper), you should
specify that part of a pathname as well, for instance:

  git show master:assets/styles/main.css
  git checkout master^3:assets/scripts/lib/jquery-min.js

-- 
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 push does not update remote workdir

[Konstantin Khomoutov]

On Fri, 24 Apr 2015 11:59:33 -0700 (PDT)
Konrád Lőrinczi  wrote:

[...]
> mkdir /domains/git/site-bare.git
> cd /domains/git/site-bare.git
> git --git-dir=. --work-tree=/domains/site/test-workdir/. init
> git config receive.denycurrentbranch ignore
> cd /domains/git/site-bare.git/hooks
> nano post-receive
> # add the following content until # end
> #!/bin/sh
> export GIT_WORK_TREE=/domains/site/test-workdir/.
> export GIT_DIR=/domains/git/site-bare.git/.git

^^^ This.

The GIT_DIR environment variable tells Git where the "Git database
directory" is located.
But a bare Git repo *is* the Git database directory in itself.
That makes it different from a "normal" Git repository, in which the
root directory is the so-called work tree, and the Git database
directory is typically located beneath and called ".git".

Obviously, in a bare repo, there's no ".git" subdirectory.
Bare repos even typically have the ".git" suffix appended to their names
precisely to signify they already are ".git directories".

[...]

> git push web-remote master
> 
> 
> Once I also got the 
[...]
> remote: fatal: Not a git repository:
> '/domains/git/site-bare.git/.git'

That most probably was the message a Git program run from your hook
script yelled at you.  Since you did not enable/provide proper error
reporting in your hook script, even though `git checkout` failed with
that error message, the script continued to chug along and hence the
receive operation succeeded.

[...]
> Later I did not get such "Not a git repository" error.

Did the hook run?
If you had no new commits to push, the hook was not run.

> But anyway, the workdir is not filled with content, this is my
> problem.
> 
> UPDATE: If I do "git checkout -f" of the server, then the workdir is 
> updated. So this means that the post-receive hook is not executed.
> 
> Any idea why the remote workdir is not updated?

There are many issues with your approach.

The first one is that your GIT_DIR setting is incorrect (and outright
nonsensical) as I expained above.  But I'd say it is not needed at all:
when the hook runs, it already has all the Git-related settings in its
environment.  So you only has to provide it with the location of your
work tree.

The second problem is that the hook is supposed to fail (that is, to
exit with a non-zero exit code; supposedly having printed out an error
message to the standard error stream before doing that) as soon as it
encounters an error.  In your case I'd start with placing the line

  set -e -u

somewhere right after the shebang line (that #!/bin/sh thing).  This
would ask the shell to crash and burn as soon as any command it
executed failed (and that was not properly handled by the script) or
the script attempts to dereference a variable which was not assigned a
value.

I would also say that the correct event for the hook like yours is
post-update, not post-receive.  Receiving deals with, well, receiving,
while post-update means the heads (branches) were already updated with
their new commits.

And another pro-tip.  If you need to debug a script, running
non-interactively, a useful "trick" is to wrap it in another script,
something like this:

  #!/bin/sh
  set -e -u
  orig="`dirname '$0'`/post-update.orig"
  exec /bin/sh -x "$orig" $@ >/var/tmp/my-hook-trace.log 2>&1

Where your post-update.orig is the original script to debug, and the
script I showed is temporarily made the post-update hook.
The "-x" command-line option instructs the shell to trace the execution
of the script it's told to run, and that trace ends up in the log file
-- with all the diagnostic and error messages.

-- 
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 push does not update remote workdir

[Konstantin Khomoutov]

On Fri, 24 Apr 2015 12:54:57 -0700 (PDT)
Konrád Lőrinczi  wrote:

> Well, I noticed, that I had a bug in  post-receive hook, so here is
> the fixed one:
> 
> #!/bin/sh
> export GIT_WORK_TREE=/domains/site/test-workdir/
> export GIT_DIR=/domains/git/site-bare.git/
> cd $GIT_DIR
> git checkout -f
> 
> However, the problem still remains.
> 
> Also GIT_TRACE=1 did not help, there was no any useful info.

GIT_TRACE only traces your local Git instance, and has nothing to do
with the Git process working on the server side.

On the other hand, exporting GIT_TRACE=1 will be an interesting thing
to do before running `git checkout -f` if you're debugging your hook
script like I have outlined in my first response.

P.S.
I would restate that you supposedly has to start using `set -e` or,
better, `set -e -u` in your hook script.  Start with [1] and the
pointers it gives.  Otherwise your hook script, as a program, is almost
as broken with regard to error handling as a typical PHP program: when
an error happens, it gets logged somewhere and the execution continues.
This is a broken logic: if you *know* you should ignore an error
running a particular command, you specifically arrange for ignoring its
error return, like with

  a_command_which_is_ok_to_fail || true

to make the script not exit when that command fails.
Otherwise anything which gone wrong will terminate the scipt.

1. http://serverfault.com/q/143445/118848

-- 
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] difference between working copy and working directory

[Konstantin Khomoutov]

On Mon, 27 Apr 2015 09:34:10 -0700 (PDT)
Pawel Por  wrote:

> Is there any difference between working copy and working directory ?
> If so what's the difference ?

Officially, Git uses the terms "work tree" and "working tree" to refer
to a directory which contains files you're working on.

In more technical terms, this is the directory which content Git
uses to physically represent what's recorded in its index (also called
"the staging area").  That is, when you `git checkout` a branch (or
directly a revision), Git first populates its index with the state of
all the files representing your project at that branch/revision and then
updates the work tree.  When you run `git status` Git as well compares
what's in the index with what's in the work tree.

As to the validity of your terminology, this is a philosophical
question ;-)  As you can see, from a purist approach, all the terms you
mentioned are incorrect, but from a more down-to-earth standpoint they
seem to be mostly OK.  "Mostly", because you should be careful with the
term "working directory": this is a concept existing in many (most?)
popular operating systems in wide use today, and it means a special
property of any running process (a program being executed).  This
property contains the path name of a directory that process explicitly
set as its current, or inherited from its parent process.  This
property is needed for the operating system to know what to do if the
process asks it to access a file with a relative name, like in «hey, OS,
please open a file named "foo/bar.txt"»; in this case the OS gets the
working directory of that process, prepends its name to the name of the
file it was asked to open and proceeds with the request.  The working
directory is also the current directory in a shell -- that is, the
thing you operate with the `cd` command in most shells.

"Working copy" is better but then again, what is it a copy of?

Note that those coming from Subversion and some other popular SCMs
might use the term "checkout" or "current checkout" even though this
usage is quite dubious when it comes to Git.

In the end, when talking about Git, I'd stick to "work tree" or
"working tree".

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: having trouble compile git from source

[Konstantin Khomoutov]

On Monday, April 27, 2015 at 11:49:36 PM UTC+3, Oscar wrote:
> I am trying to install git 2.3.6 on rhel6. Had trouble while it is installing 
> gui, so I decided to turn off gui install by "make NO_TCLTK=YesPlease". 
> However, during the install step, it failed at git-gui again. Here is the 
> error message. How do I force it not to install gui?
> 
> 
> 
> make[1]: Leaving directory `/rsrch2/rists/djiao/Downloads/git-2.3.6/gitk-git'
> make -C git-gui 
> gitexecdir='/rsrch2/rists/djiao/apps/git-2.3.6/libexec/git-core' install
Comment out the line calling

  make -C git-gui

in the top-level Makefile.

[...]

-- 
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: having trouble compile git from source

[Konstantin Khomoutov]

On Tue, 28 Apr 2015 06:57:33 -0700 (PDT)
Oscar  wrote:

> I was able to complete the install after the makefile modification.
> Most of the binaries seem to work except "git svn".Got the following
> error. I am using Perl 5.10.1. 
> 
> Can't load '/usr/local/lib64/perl5/auto/SVN/_Core/_Core.so' for
> module SVN::_Core: libsvn_swig_perl-1.so.0: cannot open shared object
> file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm
> line 200.
[...]

Do you have Perl bindings to Subversion installed?

The library Perl failed to locate is a SWIG-generated wrapper around
libsvn.  For instance, on Debian, these bindings are provided by the
libsvn-perl package; here's the listing of the files it contain [1]
(for amd64 architecture).

You did not tell us anything about your environment so we can only
guess.  In either case, the first thing to do is to see what your OS
has to offer to you to have these bindings installed, and then
verifying they're installed, and then verifying Perl looks in a correct
place for them.  If it doesn't, supposedly the build process should be
fixed further.

1. https://packages.debian.org/jessie/amd64/libsvn-perl/filelist

-- 
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: having trouble compile git from source

[Konstantin Khomoutov]

On Tue, 28 Apr 2015 07:12:15 -0700 (PDT)
Oscar  wrote:

> > > I was able to complete the install after the makefile
> > > modification. Most of the binaries seem to work except "git
> > > svn".Got the following error. I am using Perl 5.10.1. 
> > > 
> > > Can't load '/usr/local/lib64/perl5/auto/SVN/_Core/_Core.so' for 
> > > module SVN::_Core: libsvn_swig_perl-1.so.0: cannot open shared
> > > object file: No such file or directory
> > > at /usr/lib64/perl5/DynaLoader.pm line 200. 
> > [...] 
> >
> > Do you have Perl bindings to Subversion installed? 
> >
> > The library Perl failed to locate is a SWIG-generated wrapper
> > around libsvn.  For instance, on Debian, these bindings are
> > provided by the libsvn-perl package; here's the listing of the
> > files it contain [1] (for amd64 architecture). 
> >
> > You did not tell us anything about your environment so we can only 
> > guess.  In either case, the first thing to do is to see what your
> > OS has to offer to you to have these bindings installed, and then 
> > verifying they're installed, and then verifying Perl looks in a
> > correct place for them.  If it doesn't, supposedly the build
> > process should be fixed further. 
> >
> > 1. https://packages.debian.org/jessie/amd64/libsvn-perl/filelist 
> >
> Sorry, I am trying this on a Centos 6 64bit system. What kind of perl 
> bindngs should I be looking for? Is this some kind of Perl module I
> need to install from CPAN?

I have no experience with CentOS (stopped using RH products long
time ago) but googling for subversion+perl yields, among other things,
[2] which suggests that the package's name is subversion-perl.

Now I'd check if it's available directly from CentOS 6 repos, and if
no, how to make use of a suitable 3rd-party repo.

In either case, this question is really out of the scope of this
list -- if you need help with your OS then ask on suitable support
channels.

P.S.
Please don't top-post, this sucks as I have to re-format a whole lot.

2. http://opensource.wandisco.com/centos/6/svn-1.8/RPMS/x86_64/

-- 
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] Fixing a file in Git --- how?

[Konstantin Khomoutov]

On Fri, 1 May 2015 03:47:03 -0700 (PDT)
Birdy  wrote:

> I have been working with yahoo-finance 1.1.4 and it works fine with 
> Python27 but, not with Python34. I believe that I have identified the 
> changes that need to be made and would like to check if my updates
> for using it with Python34 are ok. How can I handle this via Git? [I
> apologize if this is a stupid question --- this is my first look at
> Git].

To me, it's not exactly clear what you're asking about.

The question of fixing the code and making sure it works under the
target interpreter and its libraries is completely orthogonal to Git,
and to any VCS, for that matter.

> Note, I did attempt to contact the author of this package; but,
> was unsuccessful.

This note makes question even less clear.  Do you mean that
yahoo-finance package is hosted on github and that's the reason you
want to dive into Git?  Searching for "yahoo-finance" on github brings
581 result so I'm not exactly sure.

If yes, then do you ask for hands-holding on setting up Git for using
with github, registering an account there, forking the source repo,
incorporating your changes and pushing them?

Or are you merely asking about how to best use Git to help you
gradually develop the changes necessary to fix the package?

Or are you asking something else?

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: how to git svn clone ?

[Konstantin Khomoutov]

On Saturday, May 2, 2015 at 3:37:53 AM UTC+3, Zk W wrote:

> We have a svn repo containing the following folders:
> 
> trunk
> branches
> tags
> inactive
> 
> how do we clone inactive folder since git svn clone --stdlayout only deals 
> with trunk, branches, and tags ?

Obviously, by not using --stdlayout in the first place
because your layout is not standard: `git svn` supports a set
of options which allow specifying exact layout of your repository.
These options are "--branches", "--tags" and "--trunk".
The first two can be used multiple times and are then additive.

I don't know if they can be specified along with "--stdlayout"
but you could just try and see for yourself.
The `git svn` manual explains the semantics of "--stdlayout"
pretty clearly, see for yourself [1].

1. ftp://www.kernel.org/pub/software/scm/git/docs/git-svn.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] Extend .gitignore to support setting of a file size limit so that all files over a certain size will by automatically ignored

[Konstantin Khomoutov]

On Thu, 7 May 2015 13:45:29 -0700 (PDT)
Roger Mendes  wrote:

[...]
> This seems like a fairly simple feature to add, I'm not sure why no
> one has done this or thought of it given the number of complaints,
> questions... with large file handling.
> 
> We can ignore by file name attribute, why not by file size?
> 
> Yes, I know I can add pre-commit scripts... to workaround this issue,
> but there should be a better way (or maybe I'm missing something?).

I humbly think this proposition is ill-concieved in fact.
The problem you're trying to solve using technical tools is, in fact,
social / political: if people are unable/unwilling to properly review
what they commit, they have to be educated, and then possibly penalized
on repeated faults.

I can understand why github has this setting in place: they provide
free hosting for hundreds of thousand throwaway repositories, and
obviously have to combat goofs like accidentially committing junk.
In "real" environments, like private / corporate repos, such goofs are
way easier to fix: you just tell the person to amend a commit and
force-push, or let a user with more rights do that, if required,
while explaining why things gone bad and how to avoid that in the
future.  IOW, it's possible to provide an educational hands-holding in
such a case.

On the other hand, ignoring files by name is useful for everyone as the
most common application of a VCS is managing the source code of a
program, and so you want to ignore backup files made by text editor,
IDE- or toolchain-generated crap, binary files which are the result of
compiling the source code etc.

-- 
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] migrate history from svn to git on already created git repo

[Konstantin Khomoutov]

On Tue, 12 May 2015 03:30:22 -0700 (PDT)
Yogesh Tyagi  wrote:

> Is it possible to migrate svn repo history to git when we have
> already created git repo.

Your question misses a crucial point: what is the relation between the
history in your already created Git repo and the Subversion repo you
intend to convert?  I mean, if you have an empty Git repo (have just
run `git init .`) the things are super-simple (just read the `git svn`
manual) but if the Git repo already contain some history, the number of
possible things to deal with suddenly explodes, and we need more
context.

-- 
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] Rebase onto history from another repository

[Konstantin Khomoutov]

On Tue, 12 May 2015 04:39:32 -0700 (PDT)
J66st  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] Trouble with the git-http-backend; Documentation unprecise

[Konstantin Khomoutov]

On Tue, 12 May 2015 00:40:13 -0700 (PDT)
Matthias Lantsch  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:

  
  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
  
  

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

[Konstantin Khomoutov]

On Tue, 12 May 2015 00:43:14 -0700 (PDT)
Matthias Lantsch  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.

[Konstantin Khomoutov]

On Tue, 12 May 2015 20:34:01 -0700
Michael  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] Help with git reset, please.

[Konstantin Khomoutov]

On Wed, 13 May 2015 08:29:39 -0700
Michael  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//

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

Re: [git-users] Restrict users from creating or deleting the remote branches

[Konstantin Khomoutov]

On Wed, 13 May 2015 19:06:24 -0700 (PDT)
Sakthivel D  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

[Konstantin Khomoutov]

On Wed, 13 May 2015 21:29:18 -0700 (PDT)
Massoud Yeganeh  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] Use git on microsoft words documents

[Konstantin Khomoutov]

On Thu, 14 May 2015 18:39:41 +0100
"Steve (Gadget) Barnes"  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] Use git on microsoft words documents

[Konstantin Khomoutov]

On Thu, 14 May 2015 05:44:05 -0700 (PDT)
Massoud Yeganeh  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] How to checkout files from another branch, based on a filelist from a text file?

[Konstantin Khomoutov]

On Sun, 17 May 2015 23:59:23 -0700 (PDT)
Konrád Lőrinczi  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

[Konstantin Khomoutov]

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

> John Bleichert  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 

does: it reaches for the server behind  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] How to checkout files from another branch, based on a filelist from a text file?

[Konstantin Khomoutov]

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

> Konstantin Khomoutov  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

[Konstantin Khomoutov]

On Mon, 18 May 2015 10:42:54 -0400
Michael Powell  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] Interactive rebase, reorder, squash not working

[Konstantin Khomoutov]

On Wed, 20 May 2015 09:25:37 +0200
Magnus Therning  wrote:

[...]
> >>> 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"?
> >
> > Using TortoiseGit, I "Show Log", and review, yet the same revisions
> > are in the same order, which leads me to believe that nothing
> > actually happened.
> >
> >> 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?
> >
> > Actually, no. I did not see anything like applying patches, etc.
> > There was a very succinct, one line response. Probably indicating
> > that nothing actually happened.
> 
> How are you initiating the rebase, via command line or TortoiseGit?
> 
> 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.

I checked if Windows 7 still includes the venerable edit.exe from the
MS-DOS time (Windows XP did have it) but it seems it doesn't anymore,
and Git for Windows ships with Vim which is a console editor and hence
it should reliably work for that edit -> close -> continue cycle.

Sure, for a Windows user Git is quite atypical, but one just have
to learn to hit  to go to insert mode -- familiar for most Windows
users -- fool around using cursor keys, ,  etc
and then hit  to return to normal more, where the ZZ command
should save and quit.

So I'd change the editor temporarily by

  git config --local --add core.editor vi

and retry the rebase changing the first "pick" to "edit" and see what
happens: if the rebase will continue and stop at that edit, the OP
will be able to just run

  git rebase --abort

to, well, abort the rebase.

Hence, if that works, we'll be able to work on how to properly hook
Notepad++ there.  Otherwise the problem is elsewhere and probably
the way to go would be running `git rebase` in trace mode.

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

[Konstantin Khomoutov]

On Thu, 21 May 2015 09:39:14 +0200
Magnus Therning  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

[Konstantin Khomoutov]

On Fri, 22 May 2015 04:04:43 -0700 (PDT)
Kalpa Welivitigoda  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

[Konstantin Khomoutov]

On Fri, 22 May 2015 14:19:08 +0300
Konstantin Khomoutov  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.