Re: [git-users] Middleware chaining for git hooks

2019-03-06 Thread Konstantin Khomoutov
On Tue, Mar 05, 2019 at 05:38:14PM -0800, debo via Git for human beings wrote:

> I wanted to see if there was any interest in extending support for allowing 
> a user to chain middlewares for git hooks. Currently, only one script can 
> be attached per hook, so a good-to-have item could be to allow chaining of 
> multiple scripts for a given hook, that follows a pre-defined configuration.

But this is trivially handled by creating an "umbrella" hook which would
look into any sort of "registry" of other hook scripts - a dedicated
directory in the simplest case - and execute them one by one, recreating
the setup suitable for each of them. (A family of the popular Linux-based
operating systems even have a ready-made solution for running a set of
scripts located in a named directory [1].)

I mean, what you want is already trivially doable with the current
mechanics.

1. https://manpages.debian.org/run-parts

-- 
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 push on remote if featured branch is behind one commit

2019-03-04 Thread Konstantin Khomoutov
On Mon, Mar 04, 2019 at 08:34:39AM -0800, Keshav Bathla wrote:

> Currently while working in feature branch i have done some mistake so due 
> to which i have to come behind one commit (git reset ---hard HEAD^ ) but 
> the problem i was facing now is that the deleted commit is on remote 
> feature branch. So now when after changes on local feature branch and try 
> to push the git thows error that my remote branch is behind one commit. 
> 
> Now the solution i have in mind is to force push (git push -f origin 
> feature branch) but i was strongly discouraged by my project community to 
> not to do force pushing and i know it's dangerous too.
> 
> So please help me to find alternative solution for that.

The first thing to understand is that force-pushing is *not* a solution
for this problem: you explicitly stated that deletion of that commit was
an error, so if you were to force-push your current state - which does
not have that commit - you would nuke that commit from the remote
branch, too.

Any real solution should end up with the following state: get that
commit into your local branch "as is" and then arrange for the work you
have already done on the local branch to be somehow re-applied on top of
that commit. It would make your local branch to appear as if the
deletion did not happen at all.

Now let's do it.

First, chances are high you still have the deleted commit available.

Let's pretend the branch you're messing with is called "foo", and the
remote repository you intend to push it is known as "origin", and the
branch you intend to push to is called "foo" in that repository.

Now run `git fetch origin` to make sure your local repository has the
deleted commit: this command will fetch the state of the "foo" at
"origin".

Now run `git log` on both "foo" and record (say, copy to the clipboard)
the SHA-1 name of the first commit you have created locally on "foo"
(compared to "origin/foo"). Let's say that name is deadf00d.

Next, run (assuming "foo" is checked out):

  $ git rebase --onto origin/foo deadf00d~

(notice the '~').

This command tells Git to do the following:

1) Take the commit deadf00d and all its child commits on "foo" and save
   them away.

2) Reset the head of the currently checked out branch "foo" to point to
   the same commit "origin/foo" points at.

3) Re-apply the commits saved at the step 1 to the now-current head of
   "foo".

The end result will be that you will have your local work applied on top
of how "foo" looks in the remote repo. It will be safe to push then.

Be sure to read 
for more info.

-- 
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 READ THE RESULT OF GIT FETCH

2019-02-28 Thread Konstantin Khomoutov
On Thu, Feb 28, 2019 at 06:15:54PM +0300, Konstantin Khomoutov wrote:

[...]
> > The asterisk ('*') is a marker to indicate the current branch.
> > 
> > The '->' symbolised 'has moved to', so we have that the special variable
> > FETCH_HEAD now hold the hash name of the develop branch.
> 
> I would still say it's not a "special variable" but rather a "special
> reference" - to stay within the official Git lingo.
> 
> To the OP: a reference in Git is any symbolic name which refers to
> something. Branches and tags are references, and so are special ones -
> such as HEAD, ORIG_HEAD, FETCH_HEAD, MERGE_HEAD and so on.

To try to provide more insight on this - a reference (usually
abbreviated to just "ref") can be used anywhere one would want to refer
to a commit.

For instance, the special ref FETCH_HEAD is updated by the `git fetch`
command, and can be used, for example, to merge the just fetched changes
into the current branch.
Not surprisingly, that's basically what `git pull` does behind the
scenes: it runs `git fetch` and then `git merge FETCH_HEAD`.

The FETCH_HEAD ref is "more special" than the rest of the special refs
in that it can hold more than one record at a time - because it's
possible to fetch multiple branches at the same time.

-- 
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 READ THE RESULT OF GIT FETCH

2019-02-28 Thread Konstantin Khomoutov
On Thu, Feb 28, 2019 at 01:34:59PM +, Philip Oakley wrote:

(Reversed order of quoted blocks.)

>> when I fetched the particular branch named "develop" from remote
>> repository
>> 
>> the console outputs the result below
>> 
>> * branch            develop -> FETCH_HEAD
>>    bada8af..6d2389b  develop -> origin/develop
>> 
>> I barely understood "bada8af" is the hash name of develop's HEAD and
>> "6d2389b" is the name of tracking branch's HEAD hash name.
>> But i do not know what is the asterisk of the first line?
>> and what is  "->" mean in  "develop    -> FETCH_HEAD"
>> because develop branch  is not merged to FETCH_HEAD.
> The asterisk ('*') is a marker to indicate the current branch.
> 
> The '->' symbolised 'has moved to', so we have that the special variable
> FETCH_HEAD now hold the hash name of the develop branch.

I would still say it's not a "special variable" but rather a "special
reference" - to stay within the official Git lingo.

To the OP: a reference in Git is any symbolic name which refers to
something. Branches and tags are references, and so are special ones -
such as HEAD, ORIG_HEAD, FETCH_HEAD, MERGE_HEAD and so on.

[...]

-- 
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] List of ignore configuration file

2019-01-24 Thread Konstantin Khomoutov
On Wed, Jan 23, 2019 at 10:15:59AM -0800, cl.robitai...@gmail.com wrote:

> Well, the first point to mention is that anyone writing help, man page and 
> information must not forget that the vast majority of readers are reading 
> such information because they do not know. This is obvious but the main 
> point is to not take for granted that they have a deep knowledge, 
> particularly when a concept is a bit "strange"...
[...]
> 2 - For the git-check-ignore. here are my suggestions
[...]

Forwarded this your message to the main Git list [1].

1.  https://public-inbox.org/git/20190123192151.uwwbkkoib7zqhoip@tigra/T/#u

-- 
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] List of ignore configuration file

2019-01-22 Thread Konstantin Khomoutov
On Tue, Jan 22, 2019 at 10:55:50AM -0800, cl.robitai...@gmail.com wrote:

> Is there a way to list ALL of the ignore files that a given git uses?

Yes. This list is documented in the gitignore(5) manual page.
Run `git help ignore` to read it.

> There are tons of files and locations that git uses and Googling only 
> reports a partial list.. in my case, I had, but forgotten, both 
> ~/.gitconfig AND ~/.config/git/ignore. The later was never mentioned 
> anywhere on Google but was the culprit of my issue.

Your general problem is a wrong approach: instead of googling, you
should better have spent your time contemplating the first two
paragraphs of the manual page mentioned above.

> Ok, I know, git check-ignore be used. But not in my case!!! Here is an 
> example
> 
> git add lib
> The following paths are ignored by one of your .gitignore files:
> lib
> Use -f if you really want to add them.
> 
> 
> git check-ignore lib
> NO OUTPUT
> 
> 
> git check-ignore -v -n lib
> :: lib
> 
> 
> The 2 git check-ignore clearly say that lib should not be ignored (the NO 
> OUTPUT is me writing) while git add ignores it. So, somehow, git 
> check-ignore is misleading. Some files under lib are already under control; 
> I probably added lib/ in the ignore long time ago (so that I forgot) and 
> MAY be the reason why git check-ignore fails reporting the same behaviour 
> as git add. Just a guess though...

No, you just have a mental model about how `git check-ignore` works
different from how it's actually implemented.

Again, reading the manual page of that command should have helped.
In the intro part of that manual page, we read:

| By default, tracked files are not shown at all since they are not
| subject to exclude rules; but see ‘--no-index’.

So, the reason Git says you have 'lib' ignored when you attempt to
`git add` it is because you have this directory ignored _and_ have it
included in the commit HEAD points at (what you currently have checked
out).

To demonstrate:

  ~$ cd ~/tmp
  tmp$ mkdir zzz
  tmp$ cd zzz
  zzz$ git init .
  Initialized empty Git repository in /home/kostix/tmp/zzz/.git/
  
  zzz$ touch aaa
  zzz$ git add aaa
  zzz$ git commit aaa
  [master (root-commit) f98e522] boo
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 aaa
  
  zzz$ mkdir lib
  zzz$ touch lib/bbb
  zzz$ git add lib/bbb
  zzz$ git commit
  [master 2a63dbe] trrr
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 lib/bbb
  
  zzz$ echo 'lib/' >.gitignore
  
  zzz$ git add lib
  The following paths are ignored by one of your .gitignore files:
  lib
  Use -f if you really want to add them.
  
  zzz$ git check-ignore -v lib
  
  zzz$ git check-ignore -v -n lib
  ::  lib

So, that's precisely what you see.

Now let's add "--no-index" as suggested by the manual page - to ignore
"lib" even if we have it tracked:

  zzz$ git check-ignore -v --no-index lib
  .gitignore:1:lib/   lib

It works.


TL;DR

1) You have your "lib" directory tracked by Git.
   This means the currently checked out commit have at least a single
   file from that directory (or deeper) included.

2) You have your "lib" directory ignored.

The crux here is that the "ignoring" mechanics have nothing to with what
files Git actually tracks (as part of commits). The behaviour of the
`git check-ignore` may arguably seem weird but it's documented
nonetheless.

Hope this helps.

-- 
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] User email based on remote

2019-01-21 Thread Konstantin Khomoutov
On Sat, Jan 19, 2019 at 12:16:26PM -0800, Victor Toni wrote:

> Doing open source work (mostly via GitHub) and having an automatic setup 
> for work (installer which can put the IDE and source anywhere) I sometimes 
> end up having my public email address and and my work address mixed up on 
> commits.
> 
> I tried to group my public activities in a common directory and work 
> rrealted repositories in another but this is not always feasible.
> So my git setup which is based on directories does not work out in same 
> case.
> 
> Is it possible to assign "user.email" based on remotes? This would seem to 
> solve my problems.
> (I know that it might get confusing when using multiple remotes on the same 
> repository, but this is something I do only as an exception...)
> 

I'm not sure it's possible to achieve _exactly_ what you're after, but I
think it's perfectly possible to get you halfway there.

You could create a pre-commit hook which would roll like this:
1) If HEAD does not point to a branch, do nothing.
2) If HEAD points to a branch, read its remote. If none is configured,
   do nothing.
3) Obtain the url of the remote and compare it against a list of
   "known" remotes. Act on the result.

The crux is the check in (3): say, you configure your identity to be
associated with your $dayjob, and then have the check see whether the
remote is not your $dayjob's host(s). If so, the hook would print a
warning message telling you what's the problem and quit with a non-zero
exit code to abort creation of a commit. You would then recommit while
overriding GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL environment variables —
like in

  $ GIT_AUTHOR_NAME=foo GIT_AUTHOR_EMAIL=bar git commit ...

or using the "-c" command-line option to the "umbrella" git command:

  $ git -c author.name=foo -c author.email=bar commit ...

You could have a special Git alias to do one of the above like, I dunno,
`git foss-commit` ;-)

The commands you'd need for such a hook script, are: `git symbolic-ref`,
and `git config`.

-- 
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] removing configurations on git help!

2019-01-18 Thread Konstantin Khomoutov
On Fri, Jan 18, 2019 at 04:43:06PM +0100, stephanie mathias wrote:

[...]
> >> I think these configs should be stored at ~/.gitconfig. By deleting or
> >> editing the file, you can reset these settings.
[...]
> > Don't remove them. That's the default configuration.
[...]
> thanks guys! just to clarify, do i make a new directory called gitconfig
> and store it in there?

Well, depends on what you're after.

The file ~/.gitconfig stores the so-called "global" configuration, which
is per-user (there also exist two other levels: "system" and local to a
particular Git repository).

So, we hypothesized you have lots of stuff accreted in your global
config. If you want to delete it, simply _move_ the file ~/.gitconfig
somewhere (the easiest it so just rename it), and then see whether your
offending config stuff is gone.

There is no need to recreate that file: Git will do that automatically
whenever you call `git config` with the "--global" command-line option.

-- 
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] contribution in git organisation

2019-01-11 Thread Konstantin Khomoutov
On Thu, Jan 10, 2019 at 10:31:18PM -0800, Rohit Agarwal wrote:

> I am Rohit Agarwal , second year  b.tech(CSE)  undergraduate from IIT 
> Mandi.I am open source enthusiast .I would love to contribute inthis 
> organisation .
> I have worked these langauages HTML,CSS,JAVASCRIPT,NODEJS ,MONGODB.

Hi!

You have hit the wrong mailing list and have ostensibly selected a wrong
way to approach your target.

First, this list is used to help Git users with their problem with using
Git; the developers of Git do not participate in this list.

If you want to reach the devs, post to the main Git list; [1] details
how to do this.

But before you do this, consider these two things:

- First, Git is mostly written in C, with some parts of it written as
  POSIX shell scripts, and in Perl (two "stock" GUI front-ends are
  written in Tcl and using the Tk toolkit).

  Thus, I, for one, fail to see how your skillset could be usefully
  applied to Git. Git has a website [2], but to my knowledge it's
  a static set of pages generated from some markup sources.

  Also note that Git is a pretty "hard-core" project for a newfangled
  developer. I'd recommend to embark on simpler things for a useful
  start.

- Second, I'd recommend to start with studying what's already there.

  To my knowledge, the way for students to participate is through
  GSoCs, in which Git is usually featured. So start with reading, say,
  this recent discussion [3] and study other past discussions related
  to GSoCs [4].

1. 
https://gist.github.com/tfnico/4441562#writing-an-email-to-the-developers-list
2. https://git-scm.com
3. 
https://public-inbox.org/git/CAJKt3eP+BZkfK_yn3KYWMgmJB8_18UFr5eizmdGOY_4vM5=a...@mail.gmail.com/
4. https://public-inbox.org/git/?q=GSoC

-- 
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 checkout file with custom mtime

2019-01-09 Thread Konstantin Khomoutov
On Sat, Jan 05, 2019 at 10:44:47PM +0100, Daniel Fanjul wrote:
> I'm on Ubuntu. I do not use LFS. I track mods and saved games of
> Skyrim with git, TESV.exe sorts the saved games only by their mtime. I
> know it is not the most usual use case for git.
> 
> I agree with that viewpoint and I like the way git works right now, I
> do not want to change that. Checking out the saved games and then
> fixing the mtime works but forces a lot of unneeded I/O.

You might find this overview of git-annex vs git lfs useful:
https://lwn.net/Articles/774125/

Also see this recent thread on the Git list:
https://public-inbox.org/git/79fd2b4e-243c-a9f5-3485-2954fb0f5...@aixigo.de/

-- 
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] configure sourse

2018-12-13 Thread Konstantin Khomoutov
On Wed, Dec 12, 2018 at 05:26:56PM -0800, yu.l...@wdc.com wrote:

[...]
> > > when i configure user name, i used the command: $ git config --global 
> > > user.name "Yu Liu", 
> > > but the result is : the user name is set as Yu. 
> > > why the result is that, and how i change name to Yu Liu?? 
> >
> > This may simply mean that before running `git config` with the "--global" 
> > command-line option you have run it without one, and also without 
> > quoting your name -- like in, say 
[...]

> [image: error.PNG] 
> thank you very much for your kindly explaining. but when i remove the user 
> name, there is an error shown in the picture.

Please never post images, copy and paste text from them instead.

It's not always possible to display images (for instance, I'm reading my
mail in a console application), and the text they render is not
searcheable, and hence it does not get indexed by the Internet search
engines when your message is archived. This means the next person with
the same problem you have will not be able to search your post - and
possible answers to it (which is clearly a disservice to the community -
remember that this is not a paid support, and we're spending our time).

-- 
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] configure sourse

2018-12-12 Thread Konstantin Khomoutov
On Wed, Dec 12, 2018 at 12:57:11AM -0800, yu.l...@wdc.com wrote:

> when i configure user name, i used the command: $ git config --global 
> user.name "Yu Liu",
> but the result is : the user name is set as Yu.
> why the result is that, and how i change name to Yu Liu??

This may simply mean that before running `git config` with the "--global"
command-line option you have run it without one, and also without
quoting your name -- like in, say

  $ git config user.name Yu Liu

If yes, that command have set the config.name parameter in the
configuration of your local Git repository (inside which you have run
that command), and now this local setting overrides your global one, so
setting `git config --global user.name ...` simply have no visible effect.

"The trick" here is that Git have three levels where it stores its
configuration:

 - system: that's the system-global stuff under /etc on POSIX systems or
   %ProgramFiles%\Git - on Windows.

 - global: that's the configuration global to a particular user, kept
   under their home directory.

 - local: exists in a particular Git repository.

Each "more narrow" layer overrides the previous more wide one.
If a particular setting exists in a local repository, it's used,
otherwise the global config is consulted; failing that the system-wide
config is searched for, and finally the default setting for a parameter
is applied, if any.

Observe:

  $ git config --get-all user.name
  Konstantin Khomoutov
  
  $ git config user.name Yu Liu
  
  $ git config --get-all user.name
  Konstantin Khomoutov
  Yu

To solve the immediate problem you should remove the user.name parameter
from the local config:

  $ git config --unset user.name

Or you may be explicit:

  $ git config --unset --local user.name

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


Re: [git-users] how to move files between branches keeping the git log and git blame working

2018-12-07 Thread Konstantin Khomoutov
On Thu, Dec 06, 2018 at 10:30:18PM -0800, manoj thakkar wrote:

> I am moving files from branchA to branchB , but we loose the git blame if i 
> create the patch of the file or do a git checkout  -- filename 
> etc. 

Please be more concrete about how exactly you "move" those files between
branches. (Providing a set of exact commands would be OK.)

And while we're on it, does using the "-C" and/or "-M" command-line
options with `git blame` helps?
You may read more on them in the manual page of the `git log` command
(they are described there as they modify how the history graph is
traversed.)

-- 
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: could not lock config file .git/config: Permission denied

2018-12-03 Thread Konstantin Khomoutov
On Mon, Dec 03, 2018 at 07:45:06AM -0800, chiahunglin@gmail.com wrote:

[...]
> git remote set-url origin https://...
> 
> git complains `error: could not lock config file .git/config:
> Permission denied`. All solutions found online suggest changing with
> `chown`. But that's not the case because all dirs under the directory
> with user and group configured are with my account e.g. 
> 
> My account is , and group is . Source dir called
> my-project is stored under /path/to/parent-project.
> 
> `ls -alh` parent project dir shows
> 
> drwxrwxr-x 16   4.0K Sep 27 11:17 
> 
> And ls -alh my-project shows   
> 
> dr-x-- 10   4.0K Sep 27 10:57
>  

These permissions mean  is able to read "r" the contents of the
directory (the list of entries it contains) and make that directory
current, and traverse it - that's what "x" gives when is set on
directories.

As you can see, there's no write, "w", permission which allows to "write
into the directory" - and creating/removing a file is writing into it.

"The trick" about why "w" is needed has to do with the way to make a
so-called "atomic" update of the contents of a file on a Unix system: to
do that, you read the file, _write a copy of it_ with the updated
contents aside with the original one but with a different name and then
perform the rename(2) syscall which renames the file with the updated
contents "over" the original one. rename(2) is guaranteed to be atomic
so that it either happens successfully or fails completely.

> -r-x--  1 23 Sep 27 10:57 

This also won't allow _you_ to update the said file.
Dunno if this is intentional or not, just pointing out.

-- 
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] Collective noun for Git branch, tag, or revision

2018-11-26 Thread Konstantin Khomoutov
On Mon, Nov 26, 2018 at 06:20:15AM -0800, Ilya Vassilevsky wrote:

> Hello everyone :)
> 
> I'm developing a deployment automation tool. It can compile and deploy code 
> from a Git repository.
> 
> I would like to add a command-line argument that specifies the revision to 
> deploy. It can be a branch name, a tag name, or just a plain SHA-1.
> 
> What is the best collective noun for these?
> 
> "Revision" does not cover branches and tags. "Reference" does not cover 
> revisions. "From" is a good candidate :) but I would like to use something 
> more Git-specific.

The Git docs have two approaches to naming these things.

First any named reference to a commit is called a "ref" which is short
for "reference". You can search for "ref" just right there in the
top-level git(1) manual (run `git help git`). And that is the reason why
"reflog" is named like this and not, say, "revlog" ;-)

Second, the docs semi-informally refer to any thing which can be
resolved so a commit as "commitish" (or "commit-ish").
For instance, run `git help revisions` and search for the latter form.

Commitish is also a more wide term than "a ref or the name of a commit"
since a complex combo of '^'-s and '~'-s may be applied to a ref or the
name of a commit to refer to some other commit.
IOW, a commitish is anything which Git is able to parse in such a way to
arrive to a commit.

I think the "commitish" may sound too outlandish for people not too
familiar with Gits ins and outs, so I'd name your command-line option
just "--commit" but stated in the documentation that it really is a
"commit-ish" and the user is free to use anything which fits the bill.

If your command line parser understands unambiguous prefixes, you may
name it "--commitish" and also accept just "--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] git with "bumper lanes" for basic users

2018-10-26 Thread Konstantin Khomoutov
[...]
> > I wanted to reach out to suggest an idea I had for the git community. 
> [...]
> > Wouldn’t it be great if there was a constrained version of git that you 
> > knew would NEVER let you get into those situations? 
> 
> I doubt so: to me, it's entirely unclear where you'd draw a line across
> the continuum of all possible Git use cases so that all such cases at
> the one side of that line are guaranteed to "never" ...

Sorry, I wanted to say something like «...guaranteed to never get the
user in trouble».

[...]

-- 
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 with "bumper lanes" for basic users

2018-10-26 Thread Konstantin Khomoutov
On Fri, Oct 26, 2018 at 08:51:44AM -0700, nsjac...@g.ucla.edu wrote:

> Hello git community!

Hi!

You might have hit a wrong venue to discuss your idea.
This particular community is concentrated on helping newbie Git users
solve the problems they have with _using_ Git.

What you would like to discuss apparently belongs to the developers'
list instead - as the devs do not participate in this community anyway,
and we here have no say in the question of the direction of the
development.

So you might want to read [1] and proceed accordingly.

Still, I'd want to comment a bit on your proposal as stated.

> I wanted to reach out to suggest an idea I had for the git community. 
[...]
> Wouldn’t it be great if there was a constrained version of git that you 
> knew would NEVER let you get into those situations? 

I doubt so: to me, it's entirely unclear where you'd draw a line across
the continuum of all possible Git use cases so that all such cases at
the one side of that line are guaranteed to "never" ...

> SOLUTION: The idea I wanted to discuss is to fork git and create a “light” 
> version that constrains the functionality to avoid common pitfalls that I 
> and other users tend to get into (with some tradeoffs on functionality, of 
> course).

Creating a fork, IMO, is entirely unworkable. The reason is simple: even
though Git these days is not an exemplar of what you'd call fast-pased
development, still, it receives a hefty pile of features and bugfixes
during each of its release cycles. This means maintaining a fork will
either be a continuous uphill battle with keeping such a fork properly
tracking the upstream's development (and this includes extensive
regression testing!) or would rather quickly render it obsolete.

Instead, what I'd consider a proper path of the least resistance is
something around these two ideas:

 - Taking into account that all Git commands are grouped into the two
   layers: the "plumbing" commands and the "porcelain" commands.
   
   The plumbilg commands are the low-level ones, with their CLI "APIs"
   and output formats guaranteed to not change between Git versions
   or, at least, change only long after big red notices issued several
   release cycles prior to actually turning a breaking change on by
   default.

   The porcelain commands are what the users most of the time interact
   with. They are always implemented in terms of calling into the
   plumbing layer.

   Hence naturally it's possible to create one's own high-level Git-like
   system using the plumbing layer.

 - It's possible to arrange to "wrap" the porcelain-level commands, too.

   This may be fragile, but supposedly it's still easier to deal with
   than to maintain a true fork.

In both cases the added benefit might be in that the "new upper layer"
may be written in a language other than C.

> The idea would involve two steps to figure out how to best design such a 
> system. 
> 
> Step 1 would be to create an aggressively constrained version that may not 
> be very usable but would completely solve this problem.  We would need to 
> analyze user stories and eliminate all paths to “traps” that people get 
> themselves into.
[...]
> Step 2 would be to add certain features back in that were axed when 
> idiot-proofing from Step 1. Only features that are absolutely necessary for 
> the majority of use cases for simple projects with low complexity in terms 
> of collaboration / workflows would be added back in.
[...]

Well, that's an interesting idea but I feel like being on the fence about it.

I consider myself to be reasonably experienced in Git, and, I think,
precisely _because of this_ I think that many people value Git exactly
for it being a Swiss Army Knife-type of a VCS. That is, it's possible to
do with it almost everything you could imagine you'd want doing with a
VCS. And that's not a speculative observation: I routinely split and
squash commits, work on detached HEADs and employ fine-grained staging
of the changes before commiting (with patch editing while doing so).

On the other hand, I do understand quite many people can supposedly live
without these tools available, and I may even fathom certain development
organizations may adopt workflows which do not employ them.

One may be tempted to propose for such people and organizations to just
use a different VCS but Git has really become a lingua franca of the
development comminity these days, so this might be a counter-productive
piece of advice.

Then, I'd consider your possible approach to be sound, but then the most
crucial properly of the solution to be implemented must IMO be a full
100% compatibility with "plain" Git. And this I consider to be a much
more interesting and hard problem to attack - rather than the problem of
picking the right set of "safe" features you've presented.

As one example immediately springing to mind is what your prospective
tool would do when, say, some power user rebases a branch and then
force-pushes the result to 

Re: [git-users] Query regarding git log --author

2018-10-18 Thread Konstantin Khomoutov
On Thu, Oct 18, 2018 at 06:16:22AM -0700, Amandeep Srivastava wrote:

> Can someone please help me with the functioning of --author filter with git 
> log. 
> 
> As per my understanding, it tries to match partially the strings stored as 
> email and username in git config, and it's case sensitive. 
> 
> Am I right about it? Is there some documentation regarding this? Also, can 
> I make the filter case-insensitive?

Let's cite the documentation (you may open yours by running
`git help log`)

  --author=, --committer=
Limit the commits output to ones with author/committer header
lines that match the specified pattern (regular expression).
With more than one --author=, commits whose author matches
any of the given patterns are chosen (similarly for multiple
--committer=).

The description is terse but appears to be complete.

Precisely what parts of it you're having troubles with?

-- 
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: pre-pull hook?

2018-10-02 Thread Konstantin Khomoutov
On Tue, Oct 02, 2018 at 09:02:26AM -0700, B. Lachele Foley wrote:

[...]
> PS:  The following didn't work for us.  We tested with a "hello-world"-type 
> script:  
> 
> "Note that on *nix systems installing such a script program is as easy as 
> dropping it under any directory on the user's $PATH - so that if you put 
> a file named "foo" under, say, /usr/local/bin, then running `git foo` 
> will make the Git front-end program to find that /usr/local/bin/foo and 
> execute it. "

Sorry for confusion: the script should be named after the "git-"
pattern in order for it to work as the `git whatever` command:

  ~$ echo $PATH
  /home/kostix/bin:/usr/local/bin:/usr/bin:/bin
  ~$ cat >${PATH%%:*}/git-hello
  #!/bin/sh
  echo hello
  ~$ chmod +x ${PATH%%:*}/git-hello
  ~$ git hello
  hello
  ~$ 

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

2018-09-27 Thread Konstantin Khomoutov
On Thu, Sep 27, 2018 at 11:13:19AM -0700, mondino.m...@gmail.com wrote:

JFTR, this question was also crossposted to SO:
.

[...]

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

2018-09-27 Thread Konstantin Khomoutov
On Thu, Sep 27, 2018 at 11:13:19AM -0700, mondino.m...@gmail.com wrote:
> I tried to commit my git repo on a subversion system and something went 
> wrong. Here in detail what I've done so far: 
> 
>  1. starting from a commit on our svn, I launched this command: 
> `$git svn clone my_repo_url -s `
>  2. worked on my code (so I've made my stuff);
>  3. when all was ok I rebased everything. Since I read that svn doesn't 
> work very well with branches;
>  4. So, with a single branch (master), I ran this command: `git svn dcommit`
>  5. The push onto svn server failed (probably some conflicts to resolve). I 
> didn't want to solve those at that moment so I launched this command: `git 
> rebase --abort` (maybe I didn't read very well what it does, but git was 
> suggesting this);
>  6. Right now I have lost my solution (.sln file) and on a project I can 
> see a folder called 'Backup' (with all my classes duplicated)... wtf
> 
> The simple question is: what is happening? How can I restore my solution 
> before to the 'git svn dcommit'?
> 
> Here the output of my .git/logs/HEAD:
> 
> 5edc59acb6e200aef991d7de124008f8120ee187 
> 1234c77ff6a21551ea615bee11cd9c56f2beb839 my_name my_email 1538033064 +0200  
[...]

I'd roll like this:

  $ git rev-list --no-walk --reflog | while read c; do
  git ls-tree -r --name-only "$c" | grep -qF .sln || continue;
  echo "$c"; break;
done

This encantation will loop over all the commits kept in the reflog (the
place where Git records all "drastic movements of branch heads"),
and for each it will dump the list of files which constitute that commit,
and then try to find the string ".sln" in those filenames
(You might drop the `break` and it will list all commits containing ".sln".)

Once you've found that commit (its SHA-1 name will be printed), turn it
into a branch or a tag - say, by running

  $ git branch whatever 

and then inspect what's in that branch.

This obviously does not solve the issue with interacting with Subversion
but at least you'll be able to recover your work.


(Just in case, the shell encantation above implies you have a
sh-compatible shell such as bash or dash. Windows' cmd.exe won't cut
this script.)

-- 
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] pre-pull hook?

2018-09-27 Thread Konstantin Khomoutov
On Thu, Sep 27, 2018 at 08:52:48AM -0700, B. Lachele Foley wrote:

> Our group could really use a pre-pull hook.  Is there already a way to do 
> this?  I wrote a little wrapper script in bash for it, but that's not ideal.
> 
> Here is our use case:
> 
> The code in our repo is coupled to a database. We have made it so that all 
> the parts of the database that are controlled by developers are git-managed 
> within the repo.  However, it is often convenient or otherwise desirable 
> for the developer to edit the relevant database tables directly (in the 
> usual manner, by connecting to the DB server and using SQL commands,etc.).  
> But, if this happens, it is very important that the developer has dumped 
> the relevant data into the git-managed files and committed the changes 
> before pulling.  Doing this ensures that there will be a merge conflict if, 
> for example, two devs have modified the same row in the same table (a 
> legitimate possibility for us).
> 
> The pre-pull hook we would write would do something like this:  It would 
> dump the relevant data to temporary files and compare them with the 
> git-managed versions.  If there are differences, a pull would not be 
> allowed until the dev has made the git-managed files match the contents of 
> their database.  
> 
> I looked briefly at the source code for git.  I think I found where I would 
> need to put the new code, but also found that I would need to learn many 
> new things before making the change.  So, if I do it, there might be a 
> considerable wait.  Therefore, part 2 of this question is: does anyone know 
> who to ask about implementing this feature if there is not another way to 
> handle the situation?

Well, I think you might have been derailed a bit by your research ;-)

The thing is, `git pull`, is `git fetch` followed by `git merge` with
some magic thrown in. The magic here is the reason many seasoned Git
users suggest to not use `git pull` ever, or at least not before one
have became a seasoned Git user onself - to know what exactly happens
when they run `git pull`, and what to do if that thing fails.

Hence an approach you might try to adopt is to write your own high-level
(or "porcelain-level", as Git devs would call it) script/program which
your devs would call instead of `git pull`. That command would mimic the
behaviour of `git pull` to the necessary degree - read the current
branch's configuration to figure out what upstream repo+branch combo it
is linked to, then `git fetch` what is necessary, then run your checks
then merge - if the checks pass.
Note that on *nix systems installing such a script program is as easy as
dropping it under any directory on the user's $PATH - so that if you put
a file named "foo" under, say, /usr/local/bin, then running `git foo`
will make the Git front-end program to find that /usr/local/bin/foo and
execute it.

I do understand making this thing is an administrative burden but I'd
argue it's a lesser burden than supporting a fork of Git with your
custom patches or convincing the Git devs to implement such a feature.

Still, if you anyway want to proceed with getting in contact with the
Git devs, please follow the procedure described in [2].

1. https://longair.net/blog/2009/04/16/git-fetch-and-merge/
2. 
https://gist.github.com/tfnico/4441562#writing-an-email-to-the-developers-list

-- 
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] Will the Git project push in different folder name without using the branch feature work correctly..

2018-09-20 Thread Konstantin Khomoutov
On Thu, Sep 20, 2018 at 08:33:57AM -0700, checkmen...@gmail.com wrote:

> I have my project hosted in a gitlab server. The master branch used to
> be updated often after every local modifications and commits. 
>
> The project folder name of the initial copy is myproject. 
>
> Later I backed up this copy and started work on a local copy of the
> project with the project folder name myproject-dev. This had .git and
> I added, modified and deleted some files. I locally committed the
> changes to this copy on my local git repository. 
>
> Can I do git push origin master now so that the modifications done to
> this local copy will get fully reflected in the master branch.
>
> I had a fear of using the Git branch feature on my live project,
> That's why I did it this way. Please also mention how I could've done
> this properly using the Git branch feature.

## Background

Well, let's put these things in context first.

The first thing to understand is that Git repositories are not in any
way concerned with how you name filesystem directories containing them.
To be concrete, when you work with the Git repository located in "myproject"
or in the repository located in "myproject-dev", Git pays no attention to
the names of these directories.
So, you may well forget about these details and read on.

The next thing to consider is that at first you had two Git
repositories: on local, in the "myproject" directory, and one remote -
hosted by the GitLab server. When you literally copied the "myproject"
directory into another, "myproject-dev", you effectively cloned the
local repository at the state it had just before the copy.

Since that was a full copy (I beleive), you have also copied the
configuration of that initial local repository, and the configuration of
a Git repository stores things like the names of remote repositories it
is able to talk to and the logical linkage of branches in the local
repository with the branches in remote repositories.

This fact means it's perfectly possible to do something like

  $ git push origin master

from "myproject-dev". It will work. But there might be a problem which
has to be understood - read on.

## What to do with divegred histories, if any

I warn you up front that what will be written in a moment might be a bit
hard to absorb but fear not ;-)
When you do `git push  `, the "receiving" branch must be
fully contained in the local branch being pushed, for otherwise the push
will be rejected by the remote side.
To explain it in simple words, if your local branch ends with the line of
commits

  … → A → B → C → D

and the branch in the remote repo you're about to push to ends in the
line of commits

  … → A → B

the push will succeed - as Git will update the branch in the remote repo
with the series C → D.

If, conversely, the receiving branch would end in something like 

  … → A → B → X

the attempt to update it with C → B would obviously fail.

What this means for you, is that _if_ after copying "myproject" into
"myproject-dev" you have recorded one or more commits on "master" in
"myproject" and then pushed "master" from there into "master" hosted by
GitLab, and in the meantime recorded _another_ series of commits on
master in "myproject-dev", it is unlikely that an attempt to push
your commits from "myproject-dev" will succeed due to the reasons I
explained above.

If you will find yourself in this situation, you will need to reconcile
the divergent lines of development done in "myproject" and
"myproject-dev". The usual approach to this is as follows:

1. Make sure the latest work is pushed from "myproject" to GitLab.

2. In "myproject-dev", do the so-called rebasing:

   - Bring the latest changes from GitLab into the local repository:

 $ git fetch origin

   - Rebase your local work on top of the changes the "master" branch
 hosted in GitLab contains:

 $ git checkout master# if not done yet
 $ git rebase origin/master

3. Now push normally:

   $ git push origin master

Make sure you have read and understood [1] first.

## Branching

As to branching, the simple advice is: do not be afraid of branching.
There _are_ things needed to be understood before you use it, but
branching is the bread and butter of Git, and to really leverage the
Git's powers, you have to grok it anyway.

Since long ago, Git contains a safety belt enabled in all local
repositories: the so-called "reflog" which records past states of your
branches when you do any "drastic" action on a branch - such as that
"dreaded" `git reset --hard` call.

As usually, I would advise to read the docs first!
People for some reason like to think it's okay to go full-on in bashing
their head against a tool and pray that would work. It won't. First
learn, then do. The book at [1] is a good starting point.
If you will find it too complicated, start with [2].

1. https://git-scm.com/book/en/v2/Git-Branching-Rebasing
2. http://tom.preston-werner.com/2009/05/19/the-git-parable.html

-- 
You 

Re: [git-users] bug with --max-count option in "git rev-list" command

2018-09-13 Thread Konstantin Khomoutov
On Thu, Sep 13, 2018 at 09:13:57AM -0700, Daniel Burtman wrote:

Hi!

> I’m running git rev-list command and getting usage message instead of 
> normal output:
> 
> git rev-list --max-count=3
> 
> usage: git rev-list [OPTION] ... [ -- paths... ]
> 
>   limiting output:
> 
> --max-count=
> 
> --max-age=
> 
> --min-age=
> 
> --sparse
> 
> --no-merges
> 
> --min-parents=
> 
> Same option works fine with git log.
> 
> git log --max-count=3
> 
> commit 9e4734508472b9eb7358ef2e9d46645da84c40a9 (*HEAD ->* *develop*, 
> *origin/develop*, *origin/HEAD*)
> 
> . . . .
> 
> I’m using Git version 2.19.0 on MacOS High Sierra 10.13.6
> 
> Any ideas, suggestions regarding whether this has been noticed and ETA for 
> resolution?

I reckon the simple difference is that contrary to `git log`,
`git rev-list` makes no implicit assumption about what "ref" (a Git's
parlance for anything which references a commit - such as a branch or a
tag). That is, if you don't tell `git log` what commit(s) to start
traversing the history graph from, it assumes the HEAD ref, but
`git rev-list` expects one or more things resolvable to a commit or one
or more special options which allow to specify a group of refs: "--all",
"--branches[=pattern]" and/or "--tags[=pattern]".

So your encantation for `git rev-list` would be

$ git rev-list --max-count=3 HEAD

Please consult `git help rev-list` and `git help revisions` for more
info.


-- 
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's the point of %m in git log format?

2018-08-29 Thread Konstantin Khomoutov
On Wed, Aug 29, 2018 at 06:09:11AM -0700, Jeff wrote:

> with
> git log --pretty=format:"..."
> 
> there's a placeholder '%m', which is documented as
> 
> *%m*: left (<), right (>) or boundary (-) mark
> >
> 
> So what does it mean actually? When I use it in my format description 
> string it's always ">".

Search the manpage of the `git log` for the description of the
"--left-right" command-line option. Also see "--left-only",
"--right-only" and "--cherry-pick".

-- 
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 Bash for Windows bug v2.18.0 - Command prompt text is not appearing when typed.

2018-08-29 Thread Konstantin Khomoutov
On Thu, Aug 23, 2018 at 09:49:09PM -0700, MutualCore wrote:

> Command prompt text is not appearing when typed. It's there, I can execute 
> the commands but I can't see the text.


On Fri, Aug 24, 2018 at 03:36:38PM -0700, MutualCore wrote:

> Another bug, >git log ends up stuck in the listing and the window just 
> won't recover, even doing a CTRL+C

Hi!

This list is for discussing general problems people have with Git, not
about bugs in Git or — as in your case — in its Windows port known as
Git for Windows.

First, please make sure you have the latest GfW release, and that the
indicated problems are reproducible there.

If they are, in order to report them, please go to the Git for Windows
issue tracker [1], perform an extensive search through the existing
issues to try to find those describing your problems, and if you will
end up empty-handed, file a separate issue for each of your problems,
dutifylly following the template you will be presented.

1. https://github.com/git-for-windows/git/issues

-- 
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 tags and information as file header

2018-08-23 Thread Konstantin Khomoutov
On Thu, Aug 23, 2018 at 09:34:04AM -0700, Michael Brininstool wrote:

> Wow!  How condescending of you!  In my 35 years of programming and system 
> administration, tagging a script or config file with a label that 
> identifies which "version" it is, is essential.  When you deploy these 
> files to 10's of thousand of servers, and problems crop up over the years, 
> being able to see what version of config files the problem machines have 
> helps determine the problem scope.  Hence, I don't use git!

I don't quite grok your point.
If you want to expand @version@ in your scripts kept in Git,
it's a matter of setting up a pair of scripts calling sed or something
like this.

Keyword expansion
 - Necessarily slows down detection of the fact the checked out copy
   of a file was changed compared to its "priscine" version.
 - Is not flexible enough.

Clear/smudge filters allows you to sidestep both of these problems.

I do understand they create a necessary complexity by requiring to
actually have these filters in the place where a repository is checked
out. But this is solvable as it's possible to keep a tagged file in a Git
repository, which is not part of any commit.

I think it would be better to have some helper to do this stuff as part
of the Git plumbing layer (i.e. in the core) but alas.

[...]

-- 
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] httpd backend - repo not found.

2018-08-21 Thread Konstantin Khomoutov
On Tue, Aug 21, 2018 at 12:04:20AM -0400, CrestChristopher wrote:

> > > > Okay, the way Git works via HTTP is actually documented in [1],
> > > > and trust me, you're supposed to read it several times to understand
> > > > completely.
> > > Documented in [1] ?
> > Exactly. The numbered reference was at the mail's bottom, as usually.
> Sorry I don't follow ?

Maybe we're talking over each other's head ;-)

Here is a link to my message we're discussing:
.

If you squint at it, you'll notice it refers to a link which is then
presented at the message's bottom using the number 1 used for reference.

Is this what you're asking about? Or is it something else completely?


I guess you may get fooled a bit with the way Google Groups work.
They present you with a (rather clumsy, IMO) web interface which allows
you to compose HTML-formatted mails with embedded links, which you can
create right there in the message editor provided by that interface.
But at the same time, each group available on Google Groups is in fact a
plain "mailing list" (see 
),
with the web interface being merely an interactive "gateway" allowing
people to post messages and read them.

Still, many "old-school" people, me included, use groups available via
Google Groups no different than other mailing lists - by receiving
messages posted there in their mail inboxes and reading/writing them
using their mail client (think of Thunderbird, Outlook etc).

"Old-schoolers" typically despise HTML-formatted mails, and consider
them being plain text, so they format them as such.  With this style,
links to external material are usually provided at the message's bottom
to not clutter the text, and are numbered. Where you want to refer to
one of those links, you insert its number.

Did I guess 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] httpd backend - repo not found.

2018-08-20 Thread Konstantin Khomoutov
On Mon, Aug 20, 2018 at 07:24:12AM -0400, CrestChristopher wrote:

>> Okay, the way Git works via HTTP is actually documented in [1],
>> and trust me, you're supposed to read it several times to understand
>> completely.
> 
> Documented in [1] ?

Exactly. The numbered reference was at the mail's bottom, as usually.

-- 
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] httpd backend - repo not found.

2018-08-14 Thread Konstantin Khomoutov
On Tue, Aug 14, 2018 at 02:24:30AM -0700, christian.tre...@itsv.at wrote:

> i am trying to set up gitweb and the http backend. gitweb works so far, but 
> the http backend is giving me headaches. i always get "fatal: repository  
> not found  errors, which is quite frustrating as gitweb works perfectly 
> well with the same url. i wasted hours on this, so any help would be really 
> nice!

Setting this stuff right might indeed be tricky.

I would highly recommend you to first disable mod_rewrite altogether and
try to get it working without it. The reason is that in my personal
experience (with web developers) using mod_rewrite is their first and
often the sole tactic in trying to solve any issue of mapping URLs to
the filesystem, and unfortunately, mod_rewrite is another moving part in
the already complicated gizmo, and the way it moves is not obvious.

Okay, the way Git works via HTTP is actually documented in [1],
and trust me, you're supposed to read it several times to understand
completely.

One of the major takeaways from it is that base part of your "Git" URL
must be mapped to the filesystem pathname of the `git-http-backend`
binary installed in your system. IOW, if you cant, say, your repos to be
located via, say, "http://test.sozvers.at/git/...; URLs, the base path
"/git/" (notice the trailing slash!) on the vhost serving
"test.sozvers.at" must map exactly to something like
"/usr/lib/git-core/git-http-backend/" (notice the trailing slash,
again!). The pathname shown is okay for Git packaged for Debian (and its
derivatives; check the package provided by your OS) to find out where
the git-http-backend binary is located on your system.

A typical way to map base pathnames from URLs to the git-http-backend
binary is through the ScriptAlias directive, like in

Here is a skeleton example of a vhost serving both Git and Gitweb:


ServerName  git.domain.local
ServerAlias git

ServerAdmin webmaster@domain.local

DocumentRoot /var/www/git


Require all denied
AllowOverride none
Options none



Options +FollowSymLinks +ExecCGI
AddHandler cgi-script .cgi


ScriptAlias /git/ /usr/lib/git-core/git-http-backend/



To make it fully working, you'd have to set up the GIT_PROJECT_ROOT
environment variable in your vhost config for Git to be able to find
the repositories. See [1] for more info.


After having the basic stipped down setup working, you may add
proper  directives to tighten access controls, if needed.


One another possible caveat is that if you're using mod_suexec to make
Git repos be served using the credentials of a dedicated user -
different from that of the web server process is using - stuff gets more
complicated as mod_suexec strips all the environment variables set in
the vhost config. If you have this situation, ask away as I have a
workaround.

1. 
https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-http-backend.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] to get previous tag

2018-08-13 Thread Konstantin Khomoutov
> > Thank you for the response.
> > Just wanted to know is there any way i can get the previous tag details.
> 
> Let me know if you have any specific troubles interpreting the
> explanation of your problem in my original response.

Sorry, my explanation indeed skipped a crucial bit of the logic.
Please see the corrected text below.

[...]
 when i try to execute the below command it throws me an error

 $git describe --abbrev=0 --tags $(`git rev-list --tags --skip-count=1
 --max-count=1`)
 Error:  fece0ddf3d4ef9b61640b5ae4c3c5f0e3abaf326: command not found.
>>> [...]
>>>
>>> When your shell sees a `...` construct, it takes the text between the
>>> backticks, executes it as a comand and replaces the source text and the
>>> backticks with the output that command sent to its standard output
>>> stream. For the `git rev-list` command, this is the SHA-1 name of a
>>> commmit.
>>>
>>> When the shell sees a $(...) construct, it does with the text between
>>> the opening "$(" and the closing ")" and treats it almost the same way
>>> it does for the `...` construct (the exact differences are of no
>>> interest here).

The paragraph above instead should be:

  When the shell sees a $(...) construct, it processes the text between
  the opening "$(" and the closing ")" in almost the same way it does when
  expanding a `...` construct (the exact differences are of no interest here).

Now I hope the following is clear:

>>> So what happens here is that you ask the shell to interpret the SHA-1
>>> name of a commit found by the `git rev-list` command as another command.
>>> There is no point doing that.

In other words, you first apply the so-called "command substitution"
using the `...` construct and then try to apply to its result - which is
a string containing a SHA-1 hash value - a slightly different form of
command substitution, which fails.

[...]

-- 
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] to get previous tag

2018-08-13 Thread Konstantin Khomoutov
On Mon, Aug 13, 2018 at 07:10:11PM +0530, shobha shobha wrote:

> Thank you for the response.
> Just wanted to know is there any way i can get the previous tag details.

Let me know if you have any specific troubles interpreting the
explanation of your problem in my original response.

> > [...]
> > > when i try to execute the below command it throws me an error
> > >
> > > $git describe --abbrev=0 --tags $(`git rev-list --tags --skip-count=1
> > > --max-count=1`)
> > > Error:  fece0ddf3d4ef9b61640b5ae4c3c5f0e3abaf326: command not found.
> > [...]
> >
> > When your shell sees a `...` construct, it takes the text between the
> > backticks, executes it as a comand and replaces the source text and the
> > backticks with the output that command sent to its standard output
> > stream. For the `git rev-list` command, this is the SHA-1 name of a
> > commmit.
> >
> > When the shell sees a $(...) construct, it does with the text between
> > the opening "$(" and the closing ")" and treats it almost the same way
> > it does for the `...` construct (the exact differences are of no
> > interest here).
> >
> > So what happens here is that you ask the shell to interpret the SHA-1
> > name of a commit found by the `git rev-list` command as another command.
> > There is no point doing that.
[...]

-- 
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] to get previous tag

2018-08-13 Thread Konstantin Khomoutov
On Mon, Aug 13, 2018 at 05:23:53AM -0700, sshobha...@gmail.com wrote:

[...]
> when i try to execute the below command it throws me an error
> 
> $git describe --abbrev=0 --tags $(`git rev-list --tags --skip-count=1 
> --max-count=1`)
> Error:  fece0ddf3d4ef9b61640b5ae4c3c5f0e3abaf326: command not found.
[...]

When your shell sees a `...` construct, it takes the text between the
backticks, executes it as a comand and replaces the source text and the
backticks with the output that command sent to its standard output
stream. For the `git rev-list` command, this is the SHA-1 name of a
commmit.

When the shell sees a $(...) construct, it does with the text between
the opening "$(" and the closing ")" and treats it almost the same way
it does for the `...` construct (the exact differences are of no
interest here).

So what happens here is that you ask the shell to interpret the SHA-1
name of a commit found by the `git rev-list` command as another command.
There is no point doing that.

-- 
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] Trying to execute git archive from an ant target

2018-08-07 Thread Konstantin Khomoutov
On Mon, Aug 06, 2018 at 10:02:06PM -0700, William Steele wrote:

> Trying to execute git archive from an ant target and make it part of a 
> deploy script—I am unable to get it to operate.  Any assistance would be 
> greatly appreciated.
> 
> 
> If I were to enter the command at the command line, it would be: git 
> archive -o update.zip HEAD $(git diff --name-only HEAD^)
> 
> When I make this an ant target:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

The problem is that the $(command [args]) construct is the so-called
"command substitution" of a (POSIX) shell. That is, when you call
(broken into two lines to fit the message's width)

  git archive -o /some/path/to/zip/deploy_changes.zip \
HEAD $(git diff --name-only HEAD^)

by hand, the shell first takes the text between the "$(" and the closing
")", executes it as a command, and replaces the whole "$(...)" thing
with the text that command printed into its standard output stream while
running. Then the shell executes the resulting command "as is".

The end result is that if that `git diff ...` encantation would print,
say, three file names, the command to be executed by the shell would be

  git archive -o .../foo.zip HEAD file1 file2 file3


So, back to your problem. Your "Ant" thing — whatever it may be —
supposedly implements a special "target" tailored specifically to
execute Git commands, but it obviously call Git directly, not via a
shell, and hence that

  $(git diff --name-only HEAD^)

thing gets passed to Git literally, as is.


There are at least two ways to solve this.
I'm not familiar with Ant so the first one will be a wild guess.

1. If Ant has a way to execute a command, collect its output
   and use it as argument(s) to pass to another command, that's the
   way to go: you first run `git diff ...` as a separate command,
   collect its output and then instruct Ant to use that output
   as the rest of arguments to call `git archive`.

2. Use the second approach with the "exec" action but make Ant
   call the shell.

   Something like this should do:

 

   
 

   The action would call the shell and then pass it _a shell script_
   to execute specified as a single parameter to its "-c" option.

-- 
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] Cloned Repository empty is in local

2018-07-30 Thread Konstantin Khomoutov
On Sun, Jul 29, 2018 at 10:31:02AM -0400, CrestChristopher wrote:

Hi!

First things first: do I understand correctly that your original problem
("cloned local repository is empty") is solved?

> Hi, I have a commit file although I'm attempting to push it to a repository,
> not github; a private repository. When doing `git remote -v` for both `push`
> and `fetch` the remote repository is listed but when I try to push to the
> private repository by means of `git push` I get this error ?
> 
> fatal: The current branch master has no upstream branch.
> To push the current branch and set the remote as upstream, use
> 
>     git push --set-upstream origin master

Uh, but Git actually told you what is wrong and offered you one way to
solve the problem; why did you ignore that?

The exact explanation of how `git push` without any extra arguments
works is kinda compilcated, and I do not see fit in diving into that
right now. In this particular case I'd do what Git suggested you to do -
run

  git push -u origin master

This will:

 1. Take your local branch named "master", push it to the remote
repository locally known as "origin" and use the pushed commits
to update a branch named "master" _there_.

 2. Record - in the local repository's configuration data - that the
local branch "master" is "linked to" a branch named "master" in
the remote repository known as "origin".

The latter would allow unadorned calls to `git push` to figure out that
you indeed meant to update "master" at "origin" with the changes done
on "master" locally.

Jumping through these hoops is needed because Git offers sheer
flexibility in dealing with multiple remote repositories and multiple
branches in it. (And this is actually exploited by Git "power users";
for instance a so-called "triangular workflow" - where you fetch changes
from one repository but push your own work into another - is reasonably
common.)

-- 
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] Show all commits for a specific file where ONLY that file was updated

2018-07-26 Thread Konstantin Khomoutov
On Thu, Jul 26, 2018 at 04:42:02AM -0700, Rob Hills wrote:

Hi!

> I am trying to get a list of commits for a specific file where ONLY the 
> file I am interested in has been updated.
> 
> If I run
> 
> git log -- 
> 
> I get a list of commits that have updated that file.  This list of commits 
> includes some that only contain my file and some that contain a number of 
> files that have been updated in the same commit.  I am trying to filter out 
> the commits that contain only one file, the one I am interested in.
> 
> Unfortunately, neither my git-fu nor my bash-fu have been up to the task so 
> far.
> 
> Any tips would be very welcome.

This can be done by a combination of the `git log -- ` you've
mentioned with a bit of shell scripting around the `git show` command
which is able to "show" Git objects of various types, including commits.

The "--name-status" option of the `git show` command displays the
changes introduced by a commit using the

  FLAG  FILENAME

format with one line per name. The "M" flag stands for "modified", "A"
for "added", "D" for deleted and so on.
So the encantation of the form

  git show --name-status --pretty=oneline 

would display a summary of the commit as the first line (it will include
the commit's SHA-1 name and the title of its message) and the rest of
the output would be those "flags+name" pairs.

So, to script the stuff, you'd call something like this (untested):

  git rev-list HEAD -- "$filepath" | while read sha; do
n=`git show --name-status --pretty=oneline "$sha" |
  tail -n +2 | grep -v "^[MAD]\t$filepath" | wc -l`
test "$n" -ne 0 && continue
echo "$sha"
  done

It should print you SHA-1 names of the commits reachable from HEAD which
"touched" (added, deleted or modified) only the file $filepath, in
reverse chronological order.

The body of the `while` loop rolls like this:

1) It calls `git show` in a way explained above.
2) Skips the the first line of its output (which contains the status).
3) From the remailing lines, which are "flags+filename" pairs, the lines
   which indicate modifications to $filepath are filtered out.
4) The remaining lines are counted, and the number of them is checked:
   - If it is zero, the commit only touched the file of interest.
   - Otherwise it also touched some other files.


A final remark is that this approach does not consider detecting file
renames and/or copies.  In order to implement this, you might need to
drop `git rev-list` and play with the "--pretty=" command-line
option of the `git log` command, and also its "-M" and "-C" options.

-- 
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] Failed network error when downloading Git

2018-07-25 Thread Konstantin Khomoutov
On Tue, Jul 24, 2018 at 01:33:45PM -0700, Cathryn Jegede wrote:

> No it doesn't,   I've tried that several times .

Unfortunately, I then tend to conclude it's an issue with your antivirus
software (which interferes with an attempt to download that installer)
or some other external problem.

A way to deal with it would be downloading the file on another computer
and then moving it to where it belongs using an USB pendrive or
something like 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] Cloned Repository empty is in local

2018-07-25 Thread Konstantin Khomoutov
On Tue, Jul 24, 2018 at 07:00:05PM -0700, Christopher wrote:

> Hi I've cloned a repository but I'm not seeing the cloned files in my local 
> repository ?

Hi!

I can think of two possibilities.


An unlikely one is that for some reason you've cloned the repository
using the "--bare" and/or "--mirror" command-line option. In this case
the resulting repository ended up being "bare"; bare repositories do not
have an area containing the checked out files — instead, they contain
the Git object database right at their top level directory.

Since the object database does not keep the files committed to the
repository "as is", this could explain why you see no files in the
clone.


A supposedly more likely case is a bit harder to explain.
When you call the `git clone` command without supplying it the
"--branch" command-line option, the local Git asks the remote repository
about the branch it considers to be "current". Having figured that out,
that branch is also made current (and checked out) in the local
repository.

In most repositories used for centralized access (such as those repos
served by Github, Bitbucket etc) the current branch is "master" but 1)
it's possible to change that, and 2) when you clone a regular non-bare
repository the current branch is the one which is currently checked out
there.

So, if for some reason the current branch of the repository you've
cloned contained no files in its tip commit, that state was faithfully
reproduced in the local repository created by the `git clone` command.

To check whether this is indeed the case, you can run

  git branch -r -v

in the resulting repository.
Look for the branch named "origin/HEAD" in the left column as this is
what defines "the current branch" in the source repository.

The material in [1] should have you covered on how Git manages branches
it grabs from a remote repository when cloning it and/or fetching from
it.

1. https://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] Failed network error when downloading Git

2018-07-24 Thread Konstantin Khomoutov
On Tue, Jul 24, 2018 at 12:29:18PM -0700, Cathryn Jegede wrote:

> Hello everyone! Whenever I try to download Git on my windows 8
> computer using chrome I get an error message : failed network error .
> I've tried Firefox and Microsoft Edge and I still get an error
> message. Please what can I do? Thanks. 

Does 

 work for you?

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


Re: [git-users] Git Hooks: How to access the files?

2018-07-11 Thread Konstantin Khomoutov
On Wed, Jul 11, 2018 at 02:53:37PM +0200, Jochen Wiedmann wrote:

[...]
> Is it possible for me to distinguish between a "bare repository" and
> the "root of a working tree"?

Uh, this is an apples to oranges comparison: a bare repository has no
work tree, and a regular repository consists of a work tree and a
directory named ".git" and containing the Git object database inside it.

So, is your question should instead be read as "how do I tell whether my
hook runs in a bare or in a normal repository"?

If yes, let's instead start with discussing what type of hook you intend
to run; otherwise we may be dragged away by discussing a non-issue
(search for the "XY problem" on the 'net).

-- 
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 Hooks: How to access the files?

2018-07-11 Thread Konstantin Khomoutov
On Wed, Jul 11, 2018 at 04:37:25AM -0700, Jochen Wiedmann wrote:

> I have studied a lot of Git hooks, both simple ones (like the ones, that 
> can be found in the "hooks" directory), as well as more complex ones (like 
> those running checkstyle), but one question remains unanswered:
> 
> Assuming, my git hooks directory is "": Can I 
> simply use "../../relative_path_to_file" to access a file in my project 
> directory? (The intention being to validate the projects contents in a 
> pre-commit, or pre-push hook.)

Depends on the kind of hook.

Some hooks are defined to run in the work tree of a non-bare repository.
Namely, hooks which have "commit", "rebase", "patch" etc in their names
are of this kind.

Still, you should not assume where your Git worktree is located the way
you supposed: Git does some setup before calling its hooks - to cite the
githooks(5) manual:

| Before Git invokes a hook, it changes its working directory to
| either the root of the working tree in a non-bare repository, or to the
| $GIT_DIR in a bare repository.

So, when a work-tree related hook runs, the current directory of the
process executing the hook will be the work tree already.


More hard-core hooks — such as "[pre-]receive", "[pre-|post-]update" etc
typically run in a server-side bare repository which does not have a
work tree attached.  For this kind of hooks, inspecting individual files
is still possible but requires usage of low-level (so-called "plumbing")
Git commands which are able to access the object database of a
repository directly.  If you need this, ask a more precise question, and
we will try to help.

-- 
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 files in exist db webdav : file size problem?

2018-07-04 Thread Konstantin Khomoutov
On Tue, Jan 23, 2018 at 01:24:24AM -0800, Attila Törcsvári wrote:

(Reformatted for better readability.)

> After several days I have found the reason why we cannot use git version 
> control on exist db mapped drive.

[...]
>>- Windows (most probably does not matter)
>>- p: drive is a mapped eXist XML DB WebDAV drive,
[...]
>> *Possible reason*
>> 
>> exist uses Milton.
>> exist WebDAV improperly reports size of file as found in 
>> http://exist-db.org/exist/apps/doc/repo/webdav.xml
>> “The size of an XML document is presented as a multiple of 4096 bytes, 
[...]

> Any ideas?

Not sure why you did not include the link to the Git-for-Windows issue
from where you have obtained that information [1], but no, as stated by
the GfW maintainer,

| That is really unfortunate. Git relies on accurate file size information,
| it cannot function without it.
| 
| I guess there are only two ways out of this:
|
| get eXist to fix this, or
| stop using Git on drives mapped into eXist's database.

Now, with a bit of patience and the keywords "exist", "webdav" and "4096"
at your hand, you should be able to find the discussion [2] happened on the
mailing list of the exist-open project. A post in it [3] mentions two
interesting things:

 - That eXist thing supports sort of black list of clients — detected by
   looking at the User-Agent header field in their HTTP requests,
   which break when the PROPFIND WebDav requests they ussue use that
   extravagant approach at returning an approximate size.

 - For those "blacklisted" clients, eXist switches to a mode which
   calculates exact resource size, and in that mode, «all XML documents
   in a collection are serialized to determine the exact sizes of these
   documents» and «you would find performance much worse than with a WebDAV
   client that doesn't care about the exact size of a document».

For me, two takeaways to do would be:

 - You may get in touch with the eXist devs and discuss this issue with
   them.

   I really have no idea how that eXist thing stores the files a client
   puts to it. It looks like it actually "looks into" XML documents
   which are stored into it and somehow stores them in a "parsed" form
   to that getting their exact size requires actually serializing them
   to byte streams — as for streaming to the client — to calculate the
   size of the result, and then throwing it away. _May be_ eXist goes
   clever when it sees a binary file, or may be it is possible to
   configure it in a way to consider all files in a particular directory
   to be opaque binary blobs.

   Or it may be possible to ask them to "blacklist" Git-for-Windows in
   the same way Mac OS X's Finder app is "blaclkisted."

   In other words, I would ask whether and how it's possible to make
   eXist report precise file sizes when GfW asks for them.

 - It appears that unless eXist may be somehow made not look into the
   files it manages, working around the issue — say, by faking the
   User-Agent field Git uses in its HTTP requests — has a great chance
   of slowing things down.


All-in-all, I see no real reason in trying to fix what it appears to be
very broken right from the start. Instead of battling astoundingly weird
"remote Git on a network drive backed by WebDav" setup, it would be
better to spend your energy on convincing your management to switch to a
more sane setup. In corporate setups, Git can be made use SSO when
authenticating against HTTP servers, so control freaks may control what
they want just fine without hampering the users or lowering the level of
security. And this setup will work _much_ faster than the nonsense you
have deployed at the moment.


1. https://github.com/git-for-windows/git/issues/1452
2. https://sourceforge.net/p/exist/mailman/message/30591159/
3. https://sourceforge.net/p/exist/mailman/message/30591698/

-- 
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] hash collision in git

2018-06-28 Thread Konstantin Khomoutov
On Thu, Jun 28, 2018 at 05:48:01AM -0700, 1141185...@qq.com wrote:

> Thanks for reply.  I know it is not a common scenario in real world, but 
> when we put our valued code and docs in git, we hope git will be robust 
> enough to   take  good care of our docs,  and wont fall because of some 
> unconscious behavior.

I would reiterate the point I've already made:

>> All-in-all, this particular list is for helping newbie users solving 
>> their problems they have when _using_ Git; the question of its 
>> development are discussed on another — main — Git list which is [4]. 
[...]
>> 4. http://vger.kernel.org/vger-lists.html#git 

So, if you feel like voicing your concerts before those who really are in
position to actually do something about it, this place is definitely not
suitable simply because no Git developers read this list.

Hence I urge you to post to [4] instead.

But before you doing this, please read [5].

5. 
https://gist.github.com/tfnico/4441562#writing-an-email-to-the-developers-list

-- 
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] Contributing to Git itself

2018-06-27 Thread Konstantin Khomoutov
On Wed, Jun 27, 2018 at 09:25:12AM +1000, Timothy Rice wrote:

[...]
> Some of the discussions are pretty interesting, eg there is currently work
> towards moving away from sha-1 (finally), and Linus Torvalds occasionally
> pipes up with some thoughts.

I'd also note that the current Git maintainer is Junio C Hamano (which
of course is also on that list), and in general, on that list, the
amount of people with mind-blowing expertise in software development is
astounding, so I, for one, enjoy lurking here. ;-)

> Even though you're already a competent developer I would recommend lurking
> on that list for a month or two before submitting a patch. I think you will
> want to have some intuition for how they like things done.

A very good piece of advice, indeed.

I would add that Git has exemplary review process, so glancing over
people commenting on other people's patch series submissions actually
helps becoming a better software developer.

-- 
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] hash collision in git

2018-06-27 Thread Konstantin Khomoutov
On Wed, Jun 27, 2018 at 11:00:16AM +0300, Konstantin Khomoutov wrote:

[...]
>> I have done a test in version 2.18 to test how git handle hash collision:
>> 1、I commit pdf file 'shattered-1.pdf'  into my local repo.   the generated 
[...]
> This horse has been beaten to death already.
> 
> Please start with [1] then consider [2] and if that will be not enough,
> consider researching the results of [3] and similar queries (search for
> "collisions", "preimage", "stuffing", "attack" and the other usual suspects).
[...]
> 1. 
> https://public-inbox.org/git/20170304011251.ga26...@aiede.mtv.corp.google.com/
[...]

Actually, if you're interested in discussing the possible impact of
SHA-1 hash collisions on how Git works, you should read [5], to which
[1] refers.

5. https://public-inbox.org/git/20170223164306.spg2avxzukkgg...@kitenet.net/

-- 
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] hash collision in git

2018-06-27 Thread Konstantin Khomoutov
On Wed, Jun 27, 2018 at 12:29:25AM -0700, 1141185...@qq.com wrote:

> I have done a test in version 2.18 to test how git handle hash collision:
> 1、I commit pdf file 'shattered-1.pdf'  into my local repo.   the generated 
> hash for the file is '9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0'  in dir 'ba'
> 2、I change the content of '9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0'  to 
> store some other content
> 3、then i commit another file named 'shattered-3.pdf' which is exactly the 
> same as original 'shattered-1.pdf' to my local repo. 
> 
> I expect git to reject my commit because the newly generated object have an 
> duplicate hash with and old object but the content is different. But git 
> accept my commit supprisingly.I checkout  'shattered-3.pdf'  in another 
> computer and the content is completely different with the one i
> meant to commit.
> 
> Git should reject my commit to avoid such strange behaviour. When we create 
> a new object and the hash  collides with an old object in our repo, we can 
> compare the object content byte by byte, if they are exactly the same, we 
> can use that old object directly, else we just stop creating the object 
> with an error. Out repo will not be corrupted !!

Hi!

This horse has been beaten to death already.

Please start with [1] then consider [2] and if that will be not enough,
consider researching the results of [3] and similar queries (search for
"collisions", "preimage", "stuffing", "attack" and the other usual suspects).

An executive summary is:

 - The devs are well aware of this problem.

 - They are trying to do something about this.

 - Doing this is not an easy task for a number of reasons.
   But still they're on it.

 - They think that in most real-world scenarios the problem you have
   presented is unlikely to happen.
   Still, they intend to solve it anyway.

All-in-all, this particular list is for helping newbie users solving
their problems they have when _using_ Git; the question of its
development are discussed on another — main — Git list which is [4].

1. 
https://public-inbox.org/git/20170304011251.ga26...@aiede.mtv.corp.google.com/
2. 
https://public-inbox.org/git/20180609205628.gb38...@genre.crustytoothpaste.net/
3. https://public-inbox.org/git/?q=shattered
4. http://vger.kernel.org/vger-lists.html#git

-- 
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] The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception

2018-06-13 Thread Konstantin Khomoutov
On Tue, Jun 12, 2018 at 01:28:56PM -0700, Shaobin Li wrote:

> I have an issue when installing GREET@2017 (https://greet.es.anl.gov/net). 
> A message "The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw 
> an exception" prompts when I try to open the GREET@2017. It seems that this 
> is relevant to Git on my computer. Any thoughts on how to solve this 
> issue?   GREET@2017 is working well with another desktop that do not have 
> Git.

Hi!

This issue has nothing to do with Git: the error you're getting
originates from LibGit2Sharp, which is a couple of .NET assemblies
implementing (parts of) Git functionality in .NET (note that no part of
_the_ Git is written in .NET).

So, whatever that "GREET@2017" thing is, it's apparently relying on
LibGit2Sharp to function, and — ostensibly — you're facing some .NET
configuration problem related to whatever versions of .NET you have
installed in your system and what LibGit2Sharp and/or that "GREET@2017"
want to use.

Look slike you you should use whatever support venues "GREET@2017"
provides.

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

2018-06-09 Thread Konstantin Khomoutov
On Sat, Jun 09, 2018 at 05:11:31AM -0700, Sharan Basappa wrote:

> I would like to know the difference between Git add vs commit.
> I would like to know what happens under the hood when we do git add vs git 
> commit.
> 
> Basically, I am confused why there are 2 steps before any change is pushed 
> onto the remote

https://git-scm.com/book/en/v2/Getting-Started-Git-Basics

-- 
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 on Server: Connection String to RAC-Clustered Oracle 12c Database

2018-05-11 Thread Konstantin Khomoutov
On Fri, May 11, 2018 at 10:21:29AM -0700, Roaring_Lion wrote:

> I am new to Git and in the planning stages of a migration for our SDLC 
> team.  I am going to install Git on a Win2012R2 Server for source control.  
> We are going to use Atlassian's BitBucket for the clients.  
> 
> During the setup/configuration process for Git on the server, I assume we 
> need to provide a connection string for Git to our Oracle database?  Does 
> Git require its own connection to our Oracle database used by Rational Team 
> Concert?  I assume it must for branching and merging, right?
>  
> If "yes" to above, will Git on the server be able to connect to a 
> *RAC-Clustered* Oracle 12c database on a Red Hat Server?

You might be confusing matters here - by saying "Git" while implying
some vendor-specific solution which merely uses Git in its core, for
instance (some solution from Atlassian), - but plain Git, namely the
go-to package to use Git on Windows [1], do not make use of any RDBMs,
and certainly it does not use that Oracle thingy you mentioned.

If you indeed meant to ask about some Atlassian's or whetever else's
product, please consider asking its vendor directly as this list deals
only with Git itself.

1. https://git-for-windows.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] Is there a way to find the parent branch(from which branch HEAD is detached) for detached Head ?

2018-04-10 Thread Konstantin Khomoutov
On Tue, Apr 10, 2018 at 03:46:27AM -0700, Suresh Chatti wrote:

> Is there a way to find the parent branch for detached head?
> 
>  
> 
> commands like "git log -n 1 --pretty=%d HEAD", "git show-n 1 --pretty=%d 
> HEAD" are failing when multiple branch HEADs pointing to same commit. I 
> want to know does git maintain any parent branch information when HEAD is 
> detached so that we can know from which branch it is detached.

git branch --contains HEAD

-- 
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] commit or no commit

2018-04-04 Thread Konstantin Khomoutov
On Tue, Apr 03, 2018 at 03:08:44PM -0700, KrzyJaski wrote:

> After
> git status
> 
> I got this message:
> Changes to be committed:
>   (use "git reset HEAD ..." to unstage)
> 
> modified:   root/node/chnode.c
> modified:   root/node/node.c
> 
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
> 
> modified:   root/node/chnode.c
> 
> The same file appears twice. How to understand this?

That are basics of working with Git: a commit it created not from the
state of the files in your work tree but from a so-called "staging
area".  The content to be committed is placed into that area by the
`git add` command and removed by the `git reset` command.

Please read [1] and [2].

Reading this whole book is highly recommended.

1. https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository
2. https://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] Branch for git being up-to-date

2018-03-26 Thread Konstantin Khomoutov
On Mon, Mar 26, 2018 at 01:54:54AM -0700, Shirlin Joseph wrote:

[...]
> Currently there are two main branches that we are utilizing A(master) and 
> B(branch of A). Branch is utilised for individual stories(as per delivery).
[...]

Cross-posted to [1].

1. 
https://public-inbox.org/git/84fd5584332c450abe8b634921e7b...@rew09926dag15b.domain1.systemhost.net/T/#u

-- 
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] Branch for git being up-to-date

2018-03-26 Thread Konstantin Khomoutov
On Mon, Mar 26, 2018 at 01:54:54AM -0700, Shirlin Joseph wrote:

> I have a query.
> 
> *Scenario:*
> 
> Currently there are two main branches that we are utilizing A(master) and 
> B(branch of A). Branch is utilised for individual stories(as per delivery).
> 
>  
> 
> When branch is utilised since the team size is huge the number of changes/ 
> branches created for different stories is huge and the common files changed 
> are many.
> 
>  
> 
> Thus when the story for branch A is completed and merge request is raised, 
> since the branch is not up-to-date with the A(master). It turns out to be 
> mostly a manual merge.
> 
>  
> 
> Is there a better way to handle the scenario of the branch not being 
> up-to-date with the master and the merge becoming a time consuming manual 
> merge task?
> 
> Can we automate it?

A typical approach is to simply merge A into B from time to time, or -
better - when A receives a substantial update.  The resulting history
won't be pretty but each merge will be simpler.

A better approach is simply to have smaller tasks.
That is, break down B into a series of "sub-Bs" and have each developer
working on each "sub-B" to rebase their work on A before pushing each
round of changes for review. (Another round can be performed right
before merging into A). This way you sort of "reverse" the burden of
synchronizing the lines of development into a more sensible direction -
by putting them onto those who develop new stuff.

You might find [1] to be enlightening on how one can really be creative
with branching when it comes to implementing a development scheme when
a feature can pass several "stages" of being ready for the prime time.

1.  https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb

-- 
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] Can I limit the set of files that git checks to see if they were modified?

2018-03-07 Thread Konstantin Khomoutov
On Tue, Mar 06, 2018 at 10:41:12AM -0800, Duane Knesek wrote:

> Say I have a huge source tree.  And I know that only files X, Y, and Z have 
> changed.  Is there a way (through a plug-in or otherwise) for me to tell 
> git to ignore every other file when I do a status, commit, etc.?  

Yes.
Read the git-update-index manual page about the "--assume-unchanged"
option supported by that command.

Searching the 'net for the git+assume+unchanged should have you covered with
tutorials.

Be sure to be careful with this facility though.

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


Re: [git-users] Remote repository and security

2018-03-01 Thread Konstantin Khomoutov
On Thu, Mar 01, 2018 at 12:29:04AM -0800, stefano wrote:

> Hello, I need to expose my git repository for external use.
> Which kind of protocol is better to use for security purposes?
> Ssh only? Ssh under vpn? Other solutions?

Depends on how you define "security".

Basically, there are two "secure" transports for communicating with
remote Git repositories -- SSH and HTTPS. They both are able to provide
all the three features typically assumed to be provided by "security" --
authentication, integrity, and confidentiality.
A minor difference is that in typical setups HTTPS does not provide
authentication as web servers (and other TLS-terminating software)
in their default setups typically do not require the connecting clients
to provide certificates trusted by the server.

A VPN is only needed only if you intend to use the low-level "native"
Git protocol (used for repository URLs starting with "git://") or intend
to serve your Git repository via some networking filesystem like NFS or
CIFS/SMB).


I'd also note that when hosting Git via SSH, one may want to virtualize
Git users by "hiding" them "behind" a single system user (commonly
named "git"). That's because the primary purpose of SSH is providing
logins for real users to the system. For a start, you might look at the
software package called gitolite.


To round up, you'll have to lay down your security concerns in a more
detailed manner.  I mean, both SSH and HTTPS are reasonable secure *when
it comes to protecting the data on the wire,* and the real question is
that whether you need to authenticate the clients to the server (and
authorize them subsequently).

-- 
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 commands in post-receive hook

2018-02-01 Thread Konstantin Khomoutov
On Wed, Jan 31, 2018 at 05:59:35PM -0800, Akshaya wrote:

> While using "git-svn dcommit" in post-receive hook. it fails with below 
> error.
> remote: fatal: git was built without support for git-svn 
> (NO_PERL=YesPlease).  
>   
> But the same thing works fine if we run the post-receive hook manually.
> What could be the reason?

A typical reason would be different PATH environment variables seen by
the process running the hook script when run by a Git process serving
the push and when run by a shell process when run manually.

In other words, you might have different copies of the git command
installed in the system.

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

2018-01-24 Thread Konstantin Khomoutov
On Tue, Jan 23, 2018 at 08:52:43PM +0100, Cecil Westerhof wrote:

> I just learned tcl and already made a package for it. I made a GitHub
> repository for it. Personally I like to keep all the tcl stuff in one
> repository. But there will (at a certain point) several packages and
> different scripts. What is a good way to tag a the master releases?
> 
> When upgrading a package: just the package name and the version?
> And what if I update a bunch of scripts?

This question appears to be more philosophical rather than technical.

As one example, you could look at the Tcl's stdlib, which is, while not
formally a part of Tcl, still considered to be "the standard" set of
packages.  It's released (and tagged) as a whole, when several updates
to its packages accumulate.  Secufity fixes, as usually, might warrant
special releases on their own.  Note, still, that each individual
package in the stdlib has its own version which gets incremented when
the code of that package changes.  AFAIK, such updates are not tagged
individually.  Still, some distributions (namely, ActiveTcl's "Teapot")
have each package from the stdlib packaged and available separately from
the rest of them.

If the set of packages you intend to manage is really loosely coupled,
and releasing them as a whole makes little sense, then having
per-package tags might indeed have sense but please note that in Git,
you tag commits¹, that is snapshots of the contents of the whole
repository, so your tag "foopkg-v1.0.0" would still tag the whole
repository. This will probably warrant explaining in the readme file.


¹ Well, technically you can tag anything; in particular, you can tag
  the tree object representing a particular directory—say, containing
  the code of a single package—as recorded in a particular commit.
  But I doubt the Github's web interface will be of any help there, and
  using such tags by the end user would be quite cumbersome as you can't
  checkout the target tree of such a tag using `git checkout`.

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


Re: [git-users] Feature Request

2018-01-24 Thread Konstantin Khomoutov
On Wed, Jan 24, 2018 at 09:50:27AM +1100, Timothy Rice wrote:

>> It's probably easier to let the encryption be at file system level and let
>> the hard drive handle it - maybe.
> 
> The problem with this is that it doesn't require collaborators to also use
> encryption. It also assumes that at least one of fuse and dm-crypt are
> enabled in the kernel (assuming Linux).
[...]
> So, although I don't want to discount the technical challenges that could
> be involved in providing an encryption layer for Git, I personally would be
> quite interested in whether it might be possible.
[...]

I think that encryption can be implemented with stock Git with a
wrapper.  (And I have heard of at least one commercial implementation of
this approach — IronGit™ [1]; note that I'm not affilicated with that
product/company in any way.)

One possible approach would be using the so-called clean/smudge filters
which could be set up for all types of files in a way that smudge
filters decrypt and clean filters encrypt.

But considering the whole picture hints at more general problems. I'd
list these:

 - Ideally different developers must have their own private keys so that
   they can be revoken when needed w/o affecting the rest of the team.
   The repository should not require total reencryption when this
   happens. Something akin to [2]. I'm not that versed in cryptography
   to tell whether it's possible with the contemporary algorithms.

   The same applies to digital signing (encryption w/o signing is
   not too interesting anyway).

 - The PKI part should be supported to a certain extent.

 - The set of algorithms used should somehow be future-proof (that is,
   be eligible for gradual upgrading, when needed).


Having said that, I don't *clearly* see the point of encrypting Git
repositories:

 - Shared (rendez-vouz) repositories can be hosted on properly contained
   premises and be allowed access only via trusted means (SSH with
   personal keys and/or HTTPS with personal certs being validated on the
   server side).

 - A local clone a developer makes will still have the work tree in
   order to be useful.  That is, such a repo would consist of an
   encrypted object store and one plain text snapshot of that in the
   work tree.  In order to secure this, you'd have to use
   filesystem-level or block device-level encryption, but once you start
   using it the necessity of encrypting the repository's object store
   becomes questionable.

1. https://atcipher.com/irongit/
2. https://www.schneier.com/blog/archives/2012/08/shared_lock.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 use git log without going in to repo

2018-01-10 Thread Konstantin Khomoutov
On Wed, Jan 10, 2018 at 07:25:12PM +0530, Yogi Nerkar wrote:

> Repositories accessed  remotely using SSH or HTTPS  ,so I need to close it
> for git log.

Clone, not close; otherwise correct.

> Regarding diff , I would like to see lines of code changes happened from
> last 2 months with user and date

First, I invite you to re-read what I originally wrote on this:

[...]

>> Say, you run `git log` to determine the set of all commits a particular
>> developer made since the specified timeframe. If yes, then *what* would
>> you like the diffs to be generated for? Note that the commits in that
>> set might represent completely unrelated changes, be done on separate
>> branches etc.

If you understand this, and really want to see diffs (patches) inroduced
by each individual commit made by a particular user in the speficied
timeframe, then all you need is the "--patch" command line option to
`git log`.

OK, now let's move on to `git log`. This is a high-level command which
calls lower-level stuff to carry out its task. The major two commands it
leverages are `git rev-list`, which lists in the reverse chronological
order the matching some user-specified criteria, and `git diff` which
produces the differences between two linked (parent/child) commits.

To limit the set of commits found, you have the following criteria which
must all hold simultaneously for a commit to be included in the
resulting set:
- It has a particular author;
- It was created no later than the specified moment in time;
- It is reachable from any existing reference (a branch or a tag).
The command-line options of `git rev-list` to consider for specifying
these criteria are: "--author", "--since" and "--all".
Please consult that command's manual page to gain full understanding
(run `git help rev-list`).

The ways a date for the "--since" option can be specified is explained
in the "gitrevisions" manual page (run `git help revisions` to view it).
Basically, you can use --since="2 month ago" and the like.

So, the complete command would look like this:

  $ git log --all --since="2 month ago" --author=johndoe --patch

It will:

- Select all references (branches, including remote, and tags) to start
  traversing the history graph from.
- Limit this traversal to the commits created no earlier than two month
  ago.
- Select only the commits made by a person whose name or e-mail address
  contain the substring "johndoe".
- Generate the textual difference introduced by each commit and display
  it along with the commit's metadata.

-- 
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 log without going in to repo

2018-01-10 Thread Konstantin Khomoutov
On Tue, Jan 09, 2018 at 09:09:01PM -0800, Yogi wrote:

[...]

> 1.  How do I execute git log command without going in to repo.

To answer this question, we need to know how are you accessing these
repos "normally".

I mean, if they can only be accessed via SSH and/or HTTPS, -- that is,
via "remote" transports, there's no way to traverse the histories of
such repos without cloning them locally.

If they can be accessed "directly" -- say, they are hosted on
network filesystems such as SMB/CIFS and NFS, -- then you can tell the
`git` commands to access a repository at the specific pathname through
using the environment variable (GIT_DIR) or the "--git-dir" command-line
option.

> 2.  How do I add diff command with git log mentioned above 

I, for one, fail to parse this sentence.
Care to elaborate?

The easiest approach to producing clean questions is to not attempt to
make up a single sentence but rather state what you'd like to have as a
result.

Say, you run `git log` to determine the set of all commits a particular
developer made since the specified timeframe. If yes, then *what* would
you like the diffs to be generated for? Note that the commits in that
set might represent completely unrelated changes, be done on separate
branches 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] Re: Official documentation about repository size limits for a self hosted server

2018-01-02 Thread Konstantin Khomoutov
On Tue, Jan 02, 2018 at 12:15:55AM -0800, 
antonio.poma...@external.thalesgroup.com wrote:

> > I am trying to find some official information about the limit size of a 
> > repository. As I have read git has a limitation of 2GB for each repo 
> > because if you increment the size it starts to decrease the overall 
> > performance. But this limitation is mainly explained in the web based 
> > servers like GitHub or Bitbucket Cloud. So my main question is if this also 
> > happens *when you use a self hosted server* like Bitbucket Server or 
> > GitHub enterprise. However, what I am trying to find is official 
> > documentation that explains this.
[...]
> On the other hand, to clarify my conditions as you said Konstantin
> Khomoutov, I am using Git for Windows. I cannot understand that Git
> for Windows has a practical limit of 2GB on the size of the objects
> Git is able to manipulate in memory, because I was able to do commits
> and checkouts with 3.3 GB.

That's because there is a difference between the total size of a
repository and sizes of individual objects Git manipulates when it
prepares a new commit or reads an old one.

To explain it in the simplest words I find possible, you may have a
repository containing the history of commits each containing several
millions of small files. The repo size may well be over 2 GiB but that
will not be a problem for that size limit of GfW. On the other hand,
should you try to commit a single file of the size slightly over 2 GiB
in size even into an empty repository, Git for Windows would not let you
do that, with some weird 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] Questions about pushing local branch to another (file based) branch

2017-12-05 Thread Konstantin Khomoutov
On Tue, Dec 05, 2017 at 07:14:58AM -0800, Philippe Godfrin wrote:

> Forgive my noobyness. What I am doing to learn Git is I have a 'central 
> repo' (which is not really a central) as a directory structure on a hared 
> network drive (windows H: drive). I have Git and Giteye installed. The repo 
> on the H: drive looks like this:
> 
> Directory: H:\DBA_PROD\mssql
> 
> ModeLastWriteTime Length Name
> - -- 
> d-   11/30/2017  11:05 AMprocs
> d-   11/30/2017  10:12 AMsql
> 

For a start, could you elaborate on how did you make that directory
"a repo"?

Have you run something like

  git init H:\DBA_PROD

?

The reason I'm asking is that I find the wording "I have a … repo …
as a directory structure" to be strange: a Git repo is not something you
have "as a directory structure" — it rather is a directory with contents
you typically have no business about since it's managed by Git.

So let's clear this up first.

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


Re: [git-users] How hard would it be to implement sparse fetching/pulling?

2017-11-30 Thread Konstantin Khomoutov
On Wed, Nov 29, 2017 at 06:42:54PM -0800, vit via Git for human beings wrote:

> I'm looking for ways to improve fetch/pull/clone time for large git 
> (mono)repositories with unrelated source trees (that span across multiple 
> services).
> I've found sparse checkout approach appealing and helpful for most of 
> client-side operations (e.g. status, reset, commit, add etc)
> The problem is that there is no feature like sparse fetch/pull in git, this 
> means that ALL objects in unrelated trees are always fetched.
> It takes a lot of time for large repositories and results in some practical 
> scalability limits for git.
> This forced some large companies like Facebook and Google to move to 
> Mercurial as they were unable to improve client-side experience with git 
> and Microsoft has developed GVFS which seems to be a step back to CVCS 
> world.
[...]

(To anyone interested, there's a cross-post to the main Git list which
Vitaly failed to mention: [1]. I think it could spark some interesting
discussion.)

As to the essence of the question, I think you blame GVFS for no real
reason. While Microsoft is being Microsoft — their implementation of
GVFS is written in .NET and *requires* Windows 10 (this one is beyond
me), it's based on an open protocol [2] which basically assumes the
presence of a RESTful HTTP endpoint at the "Git server side" and
apparently designed to work well with the repository format the current
stock Git uses which makes it implementable on both sides by anyone
interested.

The second hint I have is that the idea of fetching data lazily
is being circulated among the Git developers for some time already, and
something is really being done in this venue so you could check and see
what's there [3, 4] and maybe trial it and help out those who works on this
stuff.

1. 
https://public-inbox.org/git/CANxXvsMbpBOSRKaAi8iVUikfxtQp=kofz60n0phxs+r+q1k...@mail.gmail.com/
2. https://github.com/Microsoft/GVFS/blob/master/Protocol.md
3. https://public-inbox.org/git/?q=lazy+fetch
4. https://public-inbox.org/git/?q=partial+clone

-- 
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 subtree add: Import only specified folder from remote git

2017-11-21 Thread Konstantin Khomoutov
On Mon, Nov 20, 2017 at 07:47:05PM -0800, Zvi Vered wrote:

> I tried:
> git subtree split --prefix=windows 
> and got:
> adb5b0b26c0793db6cf86ee7647a4a649c2c7a8d
> 
> Then I tried to run : add+commit+push but got:
> nothing to commit, working tree clean
> 
> What should be the next step ? 

Sorry for being maybe a bit harsh but did you read the manual page of
the `git subtree` command?

Let's cite 

| split
|Extract a new, synthetic project history from the history of the
|  subtree. The new history includes only the commits
|(including merges) that affected , and each of those commits
|now has the contents of  at the root of the project instead
|of in a subdirectory. Thus, the newly created history is suitable for
|export as a separate git repository.
| 
|After splitting successfully, a single commit id is printed to stdout.
|This corresponds to the HEAD of the newly created tree, which you can
|manipulate however you want.

See that last bit?  The command printed out the name of the tip commit of the
history it synthesized, and that's what you can now subtree-merge under
your custom prefix.


Oh, and while we're at it, please keep in mind that even though your
subtree merge will bring that synthetic history under a prefix, the
merged-in history (of that directory) will not have that prefix recorded
in its commits, and that might be confusing.

I mean that if we assume that the `git subtree split` produced a line of
commits

  ...->D->E->F

and your branch you want to subtree-merge that into is currently

  ...->A->B->C

so the merge result will be

  ...->D->E->F--\
|
v
  ...->A->B->C->M

then _at the commit M,_ the contents of F will be located at the prefix
you passed to subtree merge command, but in the commit F itself, and in
all its parent commits, the contents will not be located under that
prefix -- simply because they are two separate lines of history.

It might produce confusing results when using command like

  $ git log -- path/to/the/prefix/used/for/subtree/merge

and seeing it listing no commits past M (because that's the earlies
commit actually recording something at that prefix).

If you want all the commits extracted by `git subtree split` to also
have their contents recorded under a prefix, you'd need to rewrite that
history as I've tried to explain in [1], which is a part of [2].

1. https://groups.google.com/d/msg/git-users/HXoX-kpkYkM/R4IN_3yuB24J
2. https://groups.google.com/d/topic/git-users/HXoX-kpkYkM/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] git subtree add: Import only specified folder from remote git

2017-11-20 Thread Konstantin Khomoutov
On Sun, Nov 19, 2017 at 08:15:53PM -0800, Zvi Vered wrote:

> I'm using the following command to create subtree:
> git subtree add --prefix=DRV1 https://github.com/zviered/DRV1.git master
> 
> The repo https://github.com/zviered/DRV1.git contains few folders. 
> I want my subtree to contain only one specified folder.
> 
> Is it possible ?

Yes, but not in the way you tried it.

You first need to use the `git subtree split` command to prepare a
synthetic history conststing of commits which modified only the code
under that specific directly in DRV1.

Then you will be able to `git subtree add` that line of history.

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

2017-11-14 Thread Konstantin Khomoutov
On Tue, Nov 14, 2017 at 05:37:22AM +0100, Just a Turd wrote:

[...]
> But why does something always go wrong?

Judging from what you wrote in your rant, you made use of pretty
advanced pieces of Git functionality. As with any advanced tools I can
think of, their successful usage requires advanced mastery of them.

While some people like to put forward arguments that, say, an imaginary
GUI could have successfully hands-held you through that process, I doubt
such a solution is feasible, and I don't mean that it's impossible to
create - I mean it would be impossible to use: to solitict a solution
from you in any situation where you could carry out several different
actions, it would have to educate you on the matters surrounding that
situation and ask your consent.
I'd say that such solution would be impenetrable for a human.
Consider a carpenter's toolbox, in which each of the tools tries to
educate you on the laws of physics each time you attempt to wield it.

Git does have sharp tools in its disposal. They require learning how
they work, and practicing. Or you can ignore most of them and use just
the most basic ones.

> It's such unfriendly software... :(.

Practically, I'd say you should learn about the Git reflog.
That's the special place in a Git repository which recoard each
"drastic" movement of any branch or tag being operated on.
Drastic means "which would otherwise lead to loss of the artefact being
operated on".

The reflog allows you to recover from any "oops!" case which occur from
improper assumptions about how particular Git commands behave.

-- 
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] Serena Dimnesions to GIT migration

2017-11-08 Thread Konstantin Khomoutov
On Wed, Nov 08, 2017 at 04:28:40PM -0800, Rajesh Chellaswamy wrote:

[...]
> Instead of upgrading Dimension is thr any other way to migrate the data s 
> from dimension to git 

Quite possibly yes.  Please contact the Serena Dimnesions vendor for
further assistance.

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


Re: [git-users] Re: Doing a diff of different versions of a file

2017-11-02 Thread Konstantin Khomoutov
On Tue, Oct 31, 2017 at 08:07:53PM -0700, Michael wrote:

[...]
> keybounceMBP:extractor michael$ git diff head^1 head^2 adobepass.py
[...]

…and while we're on it, can I heartily recommend you to unlearn this
habit of lowercasing the name of the ref "HEAD"?

The problem with it is that the fact it works for you is just a Git's
implementation detail combined with the semantics of the filesystems
native to Windows.  In a stock Git implementation, most of the refs
(those which are not "packed" due to age) are represented as plain files
under the ".git" subdirectory. Windows-native filesystems (at least with
default settings which no one ever touches anyway) are
case-insensitive¹.

This means when you tell Git you want it to access the "head" ref it
actually tries to find a file ".git/refs/tags/head" then
".git/refs/heads/head" then ".git/head", which succeeds because there's
a file named ".git/HEAD".

As soon as you'll happen to work with Git on a non-Windows OS with a
case-sensitive filesystem, your habit will promptly bite you in the
rear.


¹ NTFS is case-insensitive but case-preserving, so if you'll create a
file named "kAbOoM" on it, it will be stored as "kAbOoM" but you will be
able to access it by the name "kaboom" or "KABOOM" or via any other
combination of the cases of those letters.

-- 
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: Doing a diff of different versions of a file

2017-11-01 Thread Konstantin Khomoutov
On Tue, Oct 31, 2017 at 08:07:53PM -0700, Michael wrote:

> > How do I get git diff to show me the difference between two
> > different versions of one file?
> > 
> > I can say git diff tree-1 tree-2
> > 
> > I can say git diff file1
> > 
> > How do I ask for file1 in tree-1 versus file1 in tree-2?
> 
> Ok, perhaps a better question: Why isn't this doing what I expect?
> 
> keybounceMBP:extractor michael$ git status
> On branch new
> You have unmerged paths.
>   (fix conflicts and run "git commit")
>   (use "git merge --abort" to abort the merge)
> 
> Changes to be committed:
> 
> modified:   ../../.github/ISSUE_TEMPLATE.md
> modified:   ../../.travis.yml
> modified:   ../../ChangeLog
> ...
> Unmerged paths:
>   (use "git add ..." to mark resolution)
> 
> both modified:   adobepass.py
> 
> keybounceMBP:extractor michael$ git diff head^1 head^2 adobepass.py
> 
> If I understood the man page correctly, git diff tree-1 tree-2 path should 
> work.
> But that's not what I'm getting from that.

You understand the man page correcly but are you sure HEAD^1 and HEAD^2
is really what you want? To cite the manual page:

| A suffix ^ to a revision parameter means the first parent of that
| commit object.  ^ means the th parent.

That is, the encantation you presented assumes the HEAD is a merge
commit and is asking Git to compare the states of "adobepass.py"
between the two parents of the merge commit at HEAD.

We seem to discuss a *failed attempt* to merge something, and whet this
happend, there's no merge commit yet. If that was your line of
reasoning, this could explain your attempt at using ^.
Was that the case?

If yes, Git has another approach to this task.
As I've said, when you're dealing with a failed merge attempt, there's
no merge commit yet; instead, the repo is in a special state, in which
it has a special ref called MERGE_HEAD which contains one or more (for
a so-called "octopus merge") "their" heads -- those which are being
merged.

When a merge conflict occurs, for each file with one or more conflicts,
Git does the following:
- Modifies the contents of that file in the work tree by placing there
  those conflict markers delimiting conflicting chunks.
- Modifies the index entry for that file -- by placing there references
  to the *three* versions of that file's contents: "base", "ours" and
  "theirs" -- with "base" being the version at the nearest preceding
  commits both branches had before they diverged.

So it's those index entries you'd want to inspect when dealing with a
merge conflict.

The syntax you want to use is explained in the gitrevisions(7) man page:

| ::, e.g. :0:README, :README
|   A colon, optionally followed by a stage number (0 to 3) and a colon,
|   followed by a path, names a blob object in the index at the given path.
|   A missing stage number (and the colon that follows it) names a stage 0
|   entry. During a merge, stage 1 is the common ancestor, stage 2 is the
|   target branch’s version (typically the current branch), and stage 3
|   is the version from the branch which is being merged.

So supposedly you'd need

  $ git diff :2:adobepass.py :3:adobepass.py

to ask the question «what are the differences in "adobepass.py" between
the HEAD of the branch I'm merging into and the branch I'm mering?»

Still, it may turn out that

  $ git diff HEAD MERGE_HEAD adobepass.py

would be a simpler approach.

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


Re: [git-users] Why can't I push to a newly created repository?

2017-10-30 Thread Konstantin Khomoutov
On Mon, Oct 30, 2017 at 12:07:23AM -0700, Martin wrote:

> I created a repository on a home server. I can ssh to the server without 
> any issue. I can also 'git clone' the empty repository from another home 
> computer and everything works fine. 
> 
> I then tried a simple "git add, git commit". No issue! However, when I do 
> 'git push origin master', it got stuck there forever without issuing any 
> warning or error message, as below:
> 
> abigail@abilina:~/my-project$ git push origin master 
> git@10.0.0.250's password: 
>   
> 
> Counting objects: 3, done. 
> Writing objects: 100% (3/3), 208 bytes | 0 bytes/s, done. 
> Total 3 (delta 0), reused 0 (delta 0)
> 
> The push wasn't successful and got stuck like this. What could be the 
> reason? 

You mean your Git client literally hangs after those messages and does
nothing (until you, say, Ctrl-C 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] Merge master branch into feature branch without checkout

2017-10-27 Thread Konstantin Khomoutov
On Thu, Oct 26, 2017 at 10:56:14PM -0700, Mitch Negus wrote:

> When reading through this Atlassian tutorial on Git 
> , it says that 
> the set of commands
> git checkout feature
> git merge master
> can be condensed into the one-liner
> git merge master feature
> presumably to avoid needing to checkout the feature branch. I have not 
> found this command to work though. Instead, when I run the one-liner in the 
> master branch of my repository, it merges the feature branch into the 
> master branch, rather than the opposite. Is this a mistake in the Atlassian 
> tutorial, am I missing a set of circumstances where this action applies, or 
> am I maybe just misinterpreting this entirely?

I would say it's a mistake (did not read the document at the provided
link though, sorry): the basic usage of the `git merge` command is as
follows:

  $ git merge [OPTIONS] COMMIT [COMMIT...]

That is, it does not really merges branches, it merges commits pointed
to by whatever you specify — having first "resolved" them into commits.

Now if we suppose you have the "master" branch checked out, running the
command

  $ git merge master feature

is the same as an attempt to merge the tip commit of the branch you're
on ("master") and the tip commit of "feature".

An attempt to merge in the commit you're already at is a no-op:

  $ git merge HEAD
  Already up-to-date.

(and I'm not sure it's possible even with the "--no-ff" command-line
option — as this would allow creating a weird merge commit with two
or more identical parents; did not check though).

So IMO the command

  $ git merge master feature

run while being on the tip commit on "master" is the same as running

  $ git merge feature

alone, and that's what you're observing.


Let me stress again, that `git merge` works on commits, not branches.
So if you'll go into a "detached HEAD" state by checking some past
commit reachable from the tip of "master", the

  $ git merge master

*will* work.


Anothe point to make is that doing a merge w/o checking out the
"receiving" branch is (mostly) useless: "normal" merging — that is,
merging of a branch which does not fully contain the branch info which
you're merging it — may naturally result in conflicts, and these needs
to be somehow dealt with, and Git deals with them by both setting up
in a special way the index entries for the files with conflicts and
updating their contents in the work tree.

When you know your merge would result in a so-called "fast-forward"
(the case where the branch being merged in fully contains the branch
which is to be updated by the merge) you don't need the merge at all;
instead just update it by either running

  $ git push . source_branch:dest_branch

or

  $ git branch -B dest_branch source_branch

(the former is preferred as it has an extra safery check in place).

-- 
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] Where does git on windows store the repositories?

2017-10-27 Thread Konstantin Khomoutov
On Thu, Oct 26, 2017 at 07:51:24PM -0400, rhkra...@gmail.com wrote:

>> The ".git" sub-directory that stores the whole repository is normally a
>> hidden directory (as are most directories with a name starting with a
>> dot). You can make windows explorer show them by setting an option. --

> It may be helpful to add that the (hidden) .git directory is a subdirectory 
> of 
> the project directory.  (Which seems to be true in my experience--maybe 
> that's 
> not always the case?)

Two things, if we're digging deeper.

First, as was already mentioned in the first reply to this thread, Git
repositories come in two flavours: "normal" (or "regular", if you want —
in fact, they do not have any special name in Git documentation) and
"bare".

Both kinds of repositories contain the object store — a directory where
all the history and branches and tags, — that is, all the stuff — are
stored, as well as the per-repository configuration.

What makes these types of repositories different, is the presence of
absence of the so-called "work tree": a directory, where the files of
the currently checked out history revision are stored.  The user edits
these files, and that's those files they add using `git add` etc.
The repositories with the work tree are "normal", the ones without the
work tree are "bare".

Since the directory containing a normal repository *is* its work tree,
there has to be a place where the repository's object store and
configuration reside. For this, normal Git repositories normally use the
subdirectory named ".git" right in the work tree.
In a way, a normal repository is a work tree plus a bare repository in a
subdirectory of the work tree.

While modifying the history of a bare repository — such as recodring new
commits — is possible, it's inconvenient; that's why bare repositories
are mostly used as "rendez-vous" or "public" or "shared" repositories —
places where everyone push to and fetch from, and are kept on servers.
"Normal" repositories are what developers are working with on their
workstations.

Second, Git has several ways to be configured, and the location of the
object store (what's kept in ".git" normally) can be configured.
So yes, it's possible to have a work tree without any ".git"
subdirectory but that's a very unusual case; typically if you face one,
you know what and why you're doing ;-)

-- 
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] Where does git on windows store the repositories?

2017-10-27 Thread Konstantin Khomoutov
On Thu, Oct 26, 2017 at 08:55:23PM +0100, Philip Oakley wrote:

> The ".git" sub-directory that stores the whole repository is normally
> a hidden directory (as are most directories with a name starting with
> a dot). You can make windows explorer show them by setting an option.

A nitpick: filesystem entities whose names start with a dot are
considered hidden — by policy — only on Unix-y systems (I beleive,
Mac OS X counts as one in this regard, too).

On Windows, the visibility is controlled by a special "attribute" which
was available since FAT-16 at least (if memory serves me right) and was
carried forward to FAT-32 and all versions of NTFS.

Git for Windows sets it on the ".git" subdirectory in the cloned it
creates.

I think this attribute can be safely unset (using any tool, including
Windows Explorer) — this won't affect how GfW operates on such a
"tweaked" 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] Where does git on windows store the repositories?

2017-10-26 Thread Konstantin Khomoutov
On Thu, Oct 26, 2017 at 10:50:11AM -0700, Greg Quintana wrote:

> Where does git on windows store the repositories?

Git for Windows is no different from "normal" Git in this regard (and in
most others, too), so just grab any Git book / tutorial and get started.

-- 
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] Can git store a piece of data for each file to describe the function of this file?

2017-10-17 Thread Konstantin Khomoutov
On Tue, Oct 17, 2017 at 01:07:33AM -0700, 王一航 wrote:

> When I was using github, I wanted to know the purpose of a specified file 
> in a warehouse or frame, such as config.php, 
> which was used to describe the configuration file. At the beginning of the 
> warehouse owner, 
> File, the submission of the comment information may be the use of this 
> document, but once the file has changed, then it will lose the description 
> of this document
> At present, the data described in this description requires the owner of 
> the warehouse to take the initiative to write a special document
> My question is whether you can open a data structure in the git repository 
> to store the role of a file in the entire project

Yes, there are "git notes" -- see `git help notes`.

But it appears you're trying to invent a too high-tech colution for a
simple problem: what's wrong with a simple README.md having a section
dealing with all the project files of key importance?

-- 
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] Export all changed/added/Modified files Between : to a separate folder without changing the parent folder structure

2017-10-12 Thread Konstantin Khomoutov
On Thu, Oct 12, 2017 at 06:18:19AM -0700, LnT wrote:

> My Requirement : Export all changed/added/Modified files Between 
> : to a separate folder without changing the parent 
> folder structure.
>  These files will be given to SONAR Scan.
>  
> I have the Algorithm - Get updated/added/changed files Between 
> :
> 
> 1) Prepare log of changes between :
> 2) Identify all the file names from the log/history
> 3) Get pull/checkout entire repository
> 4) cherry pick all files from the list prepare in Step#2
> 5) Copy all cherry picked files to a separate location for scanning
> 
> But I wish to have more optimal solution to write my script - which will be 
> given to my Jenkins job which accepts  && 
> My setup : git version 2.12.2.windows.2

I see it can be simplified in several places.

First, there's no need to inspect the Git log: the `git diff` command is
already equipped with everything needed.

This command accepts a "--name-only" command-line option which tells the
command to only output the names of the files changed between the
specified revisions instead of the actual changes.

So, to get what was changed between the "from date" and the "to date",
you do

  $ git diff --name-only 'master@{2017-09-31}' 'master@{2017-10-12}'

which tells Git to compare the states of the repository as recorded on
the branch "master" as of 31 September, 2017 and 12 October, 2017.

Second, Git supports so-called "shallow clones": a shallow clone
contains only a minimal amount of history.  This is what usually needed
if you only need the state of files of a particular history snapshot.

Third, there's no need to cherry-pick anything.
May be that's merely just a poor wording, but I think I should warn you
just in case.  After you've cloned a repository, you have several ways
to obtain the files you need: merely copy/link them over from a work
tree (if that was a "normal" clone) or take them from the index or take
them directly from a commit of interest; the latter two approaches work
even for bare clones.

Now a word of caution.  The "--name-only" option only lists the files
which were "changed", and that also means deleted files and supposed
renames (Git does not track renames, so it tries to detect them when it
traverses the history).  This means if a file was renamed somewhere
between those two dates of interest, you can't really obtain it from the
commit at "to date".
Hence supposedly you instead need the "--name-status" option which
prefixes each file name it lists with the type of change done to that
file; these types are listed in the git-diff manual page but a quick
overview if that 'A', 'D' and 'M' stand for added, deleted and modified,
respectively, and 'Rnnn' stand for supposed rename with confidence nnn
percents (zero based, up to 100).  All states except 'M' are followed by
the name of the file, and are separated from it with a TAB character;
the 'M' state if followed by the old and the new names of the file, and
all these fields are separated with a TAB character.


Considering all of the above, I'd recommend this approach:

 1. Get the list of changed files using

git diff --names-status 'branch@{from date}' 'branch@{to date}'

 2. Process it with a tool which would collect the names of the files
in the states A and M, and the "new" names of the files in state R.

You'd need to think through what to do with possible deletions.
May be ignoring them is just OK. Or may be you'd need to fail or
log a warning -- that depends on the nature of your data.

 3. Given that list of files, deliver them to your CI server.

 4. There, call
 
  git clone --bare --branch branch --single-branch URL

That would clone just a minimum amount of history for the
branch named "branch" and set the HEAD ref in the resulting clone
to point to it.

 5. Iterate over the list of files and obtain them calling

  git cat-file blob HEAD:path/to/a/file >dest/dir/file

You might need to first `mkdir -p dest/dir` for each file
first to create a directory hierarchy.

-- 
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] Recreating repo structure without content?

2017-09-27 Thread Konstantin Khomoutov
On Wed, Sep 27, 2017 at 12:52:34PM -0400, Paul Smith wrote:

> Hi all.  I'm wondering if anyone has a script or something that will
> allow me to create a new repository which recreates the commit
> structure (parent/child, branches, merges) of an existing repository,
> but with obfuscated content.  It's OK if this is slow.
> 
> My goal is to provide a test case that can reproduce a failure that
> appears only in our long-lived and complex Git repository, without
> having to hand over the actual content of the Git repository.
> 
> Obviously the SHAs would not be the same, but that's not relevant (I'm
> sure).  My suspicion is that the problem is caused by the very complex
> spaghetti branching structure we used to live with back in 2011/2012,
> before we imposed sanity.

You need the `git filter-branch` command.

To make it as fast as possible, you can use it with the "--index-filter"
command-line option and script around it with `git cat-file` and
`git update-index`.

If you'd prefer to trade speed for easiness of implementation, consider
the "--tree-filter" command-line option 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] Locking master branch

2017-08-30 Thread Konstantin Khomoutov
On Wed, Aug 30, 2017 at 01:43:58AM -0700, Prasanth Damodharan wrote:

> In GitHub, Is there a way to lock master branch and limit access based on 
> user ids?

This list discusses Git -- and SCM/VCS system -- and has nothing to do
with Github -- a Git hosting solution.

Still, [1] looks like what you need.

1. https://help.github.com/articles/about-branch-restrictions/

-- 
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 Move from Dropbox to Git

2017-08-30 Thread Konstantin Khomoutov
On Tue, Aug 29, 2017 at 07:07:47PM -0700, Ray Joseph wrote:

> Our team is using Dropbox and we want to change to Git.  I have seen many 
> articles on how to use them together, but not how to transition.  Is it 
> possible to capture the Dropbox versioning over to a new Git repo?

DropBox has a "web API" available which can be used to retreive the list
of revisions for a particular file, and obtain each of these revisions.

So you could code up a tool which, given an URL of a project's root
folder on your DropBox account, would list the folder's contents then
walk the revisions of each file, and download them.  The simplest way to
shovel them to a Git repo is, IMO, appending them to a file formatted to
the expectations of the `git fast-import` command [1].

I'm not well-versed in DropBox semantics so I don't know whether DropBox
supports atomic updates of several files at once or each update
operation always happens on a single file (and so the commits you'll be
synthesizing for a Git repo will also be single-files).  You'd also need
to track renames (in Git, a rename is deletion of a file from its old
location and addition of it at a new one -- that is, no special "rename"
operation is supported).

I'm pretty sure there should exist ready-made libraries for popular
scripting languages to make use of DropBox API.

1. https://www.kernel.org/pub/software/scm/git/docs/git-fast-import.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] Bringing back botched history in a rebaseable state

2017-08-29 Thread Konstantin Khomoutov
On Mon, Aug 28, 2017 at 12:28:57PM +0200, Marc Haber wrote:

> > > But when I try to git rebase fan upon master, I get the same file that
> > > is even in the diff between msater and fan over and over again. I guess
> > > that git rebase goes back to commit 2357bcc where fan was branched off
> > > master and tries to reapply all changes one by one, most of which have
> > > been rolled back since then or have already been done in master. I have
> > > merged msater into fan multiple times in the hope that this would make
> > > rebasing possible again, but to no avail.
[...]
> > One way would be to merge with --no-commit then manually fixing up the
> > results (by picking the correct contents for particular files using
> > `git checkout`) and then staging the changes and comitting.
> 
> Only the issue is that I don't want to merge, I want to rebase.

Sorry, I was in a hurry and misread your actual problem statement :-(

For rebasing, one way to attack the problem is to "be explicit" about
both the range of commits to rebase and the point to rebase them onto.

You specify the range as usually -- by using the hash name of the
immediate parent of the "bottom" commit in the range, and use the "--onto"
command-line option to tell the rebase where you want to plant that
range on.

Another possibility is to identify which commit really make "fan"
different from "master", reset "fan" to point to "master" and then
cherry-pick those commits from the old state of "fan".

Since you were about to rebase "fan" anyway, there's no problem with
keeping the "fan" history untouched, I reckon.

-- 
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] Bringing back botched history in a rebaseable state

2017-08-28 Thread Konstantin Khomoutov
On Sat, Aug 26, 2017 at 12:37:55PM +0200, Marc Haber wrote:

> Hi,
> 
> whenever I think that I have finally understood how merging and rebasing
> in git works, something happens and I am confused as before.
> 
> The git history (obtained with git log --graph --oneline --decorate
> --all) pasted below shows a git repository containing my ssh
> configuration, with a master branch that is shared between machines, and
> a local branch, fan, containing changes that are needed to use ssh on
> fan. Althouth both branches have diverged at the bottom of the history,
> the entire diff is tiny.
> 
> 128 [4/4984]mh@fan:~ $ git diff master..fan | diffstat
>  head/00_dist_defaults |1 +
>  mh/5_dist_swivel  |2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> [5/4985]mh@fan:~ $ 
> 
> But when I try to git rebase fan upon master, I get the same file that
> is even in the diff between msater and fan over and over again. I guess
> that git rebase goes back to commit 2357bcc where fan was branched off
> master and tries to reapply all changes one by one, most of which have
> been rolled back since then or have already been done in master. I have
> merged msater into fan multiple times in the hope that this would make
> rebasing possible again, but to no avail.
[...]

Isn't this the case covered by this bit from the git-merge(1) manual
page?

| With the strategies that use 3-way merge (including the default, recursive),
| if a change is made on both branches, but later reverted on one of the
| branches, that change will be present in the merged result; some people
| find this behavior confusing. It occurs because only the heads and the merge
| base are considered when performing a merge, not the individual commits.
| The merge algorithm therefore considers the reverted change
| as no change at all, and substitutes the changed version instead.

I don't have a clear idea of how to deal with this properly.

One way would be to merge with --no-commit then manually fixing up the
results (by picking the correct contents for particular files using
`git checkout`) and then staging the changes and comitting.

You could also try exploring whether "ours" or "theirs" modifiers to the
merge strategy would do what yo're after, like with

  $ git merge -s recursive -X ours ...

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

2017-08-21 Thread Konstantin Khomoutov
On Sun, Aug 20, 2017 at 11:44:16PM -0700, Hyung Chul Moon wrote:

> CheatSheet for Git beginner !
> 
> https://github.com/ninanoo/gitCheatSheet
> 
> 
> 

Could you elaborate on what principle is used to group the commands
in the chart's columns?

-- 
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 log "double dot" showing a false positive?

2017-08-07 Thread Konstantin Khomoutov
On Mon, Aug 07, 2017 at 08:28:15AM -0700, Chris Murphy wrote:

[...]
> ą % git --version
> git version 2.13.0
> 
>  % git log branchA..branchB | grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> commit 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> 
> ą % git log branchA | grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> commit 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> 
> ą % git log branchB | grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> commit 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> 
> ą % git branch --contains 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc | grep 
> "branchA\|branchB"
> * branchA
>   branchB
> 
> ą % git log --left-right branchA...branchB | grep 
> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> commit > 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> 
> I believe that is an incorrect result for the double dot syntax.

Just a quick reality check: the latter command uses the triple-dot,
which is different from double-dot in its semantics.
Is it intentional or an oversight?

-- 
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 describe's way of choosing the "most recent" tag

2017-08-07 Thread Konstantin Khomoutov
On Sun, Aug 06, 2017 at 09:14:15AM -0700, Michael wrote:

> > # get most recent annotated tag (by time-of-tagging)
> > $ git for-each-ref  --sort='-*committerdate'  refs/tags | head --lines=1
> > 
> > # get most recent lightweight tag (by time-of-commit)
> > $ git for-each-ref  --sort='-committerdate'  refs/tags | head --lines=1
> 
> "for-each-ref"?
> 
> Maybe a better question: How is someone supposed to learn all the
> things that git can do? I've never seen that one mentioned.

The "root" Git manual page (which is called "git", run `git help git`)
mentions every existing Git command.

By the way it also mentions high-level but almost unknown manual pages
such as "gitcli", "gitworkflows" 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] current core.autocrlf and core.eol state

2017-08-01 Thread Konstantin Khomoutov
On Mon, Jul 31, 2017 at 05:52:41AM -0700, Ilya Kantor wrote:

> I see there were changes in the last year regarding autocrlf and eol.
> 
> I know what autocrlf does. But what core.eol does now? 
> How those two interact with gitattributes?
> 
> I saw there were changes in eol behavior.

Well, it's hard what exactly you want to hear given such broad
definitions.

If you wish to know how the said configuration variables behave in some
Git version of interest, just check its "config" manual page (run
`git help config` for instance) and "attributes" manual page -- the docs
certainly get updated along with the features.

If you'd want to know what exactly changed when, then take the list of
release notes [1], and study those of the versions happened between the
one you used and the one you're interested in (the up-to-date stable
version as of now is 2.13.3, IIRC).

You might even clone the Git repository and do something like

  git grep -Fw core.eol -- Documentation/RelNotes

to find the release notes mentioning the core.eol configuration knob.

1. https://github.com/git/git/tree/master/Documentation/RelNotes

-- 
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] A scenario where SVN has merge conflict while GIT merges succefully?

2017-08-01 Thread Konstantin Khomoutov
On Mon, Jul 31, 2017 at 09:29:29AM -0700, gqq nbig wrote:

> I'm learning GIT and I understand GIT uses pointers to track snapshots and 
> it's easier to find the common ancestor of two files.

Git never tries to find common ancestors for individual files -- only
for whole commits.  That's because commits is what history graphs
manipulated by Git are comprised of.

> Whereas, subversion has to resort to property svn:mergeinfo.
> 
> I know when I merge in svn, svn will add mergeinfo to the folder for me to 
> commit. If I don't let svn record mergeinfo, how suck will it be?

That's exactly the situation existed in Subversion before v1.5 [1] which
introduced support for merge tracking (via the svn:mergeinfo property).

Basically you had to memorise (or, which is more realistically, record
this information externally in one way or another) what revision ranges
were merged where.  Revision range to merge had to be specified by hand
when doing "reintegration" merges -- that is, merging a branch into
another the second time (and so on).

> Is there a scenario where SVN has merge conflict while GIT merges succefully?

It's hard for me to see what exactly is being asked here.
Another point which complicates matters is that there are quite a number
of moving parts involved. At a minimum, there's a diffing algorythms
which, I presume, differ in implementation between Git and Subversion
(add to this that Git has several of them, each with its own knobs, and
is able to fall back to another is one failed at carrying out the merge
operation). Another difference is that Subversion is able to do
"partial" merges in the sense you can merge any revision range of any
path -- while Git only ever operates on whole commits [*]. These things
make the both systems hardly comparable on such broad scale you seem to
have outlined.

> Can the scenario not involve a file renaming? I'm pretty sure SVN cannot 
> track renaming properly.

Actually, tracking renames -- by actually recording them in the change
history -- is one of the selling points of Subversion, and contrary to
this, Git does not record renames in any way, and uses heuristics to
detect them when doing history traversal operations (such as `git log`).

Again, I'm not sure how to talk about comparison here: Git does not
track renames but most of the time it considers whole commits when
merging, so it's okay from its point of view when a piece of information
moves from one file to another.

1.  https://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking

[*] Well, there exist subtree merges, but those are, again, whole-commit
merges, just with the added relocation of the root tree of the stuff
being merged.

You can also do manual tricks like doing a merge w/o recording the
merge commit and then zapping all the changes the "theirs" side of
the merge brings in at all paths except those in a chosen set --
emulating the Subversion's "path-wise" merging, -- and then
recording the merge commit.  But the resulting merge commit will
still reference a whole second parent commit and will look as a
regular no-frills merge to Git.

-- 
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] Bitbucket Logins How can I let multiple machines to download my Bitbucket repos at a time without login?

2017-07-28 Thread Konstantin Khomoutov
On Fri, Jul 28, 2017 at 12:23:24AM -0700, T Obulesu wrote:

> I have some 50 Raspberry pis / local machines and I want those machines to 
> download latest software/applications from my bitbucket repos automatically 
> whenever there is any update. And It shouldn’t prompt for authentication 
> every time it downloads..

Typically there are two ways to achieve this:

a) Usning unencrypted SSH keys to make the SSH client used by Git to
   not ask the password.

b) Using certain instrumentation such as sshpass [1] to make the SSH
   client ask the password but accept it in a non-interactive manner.

c) Using the ~/.netrc file read by the libcURL library which is used by
   Git when accessing repositories using the HTTP/HTTPS protocols to
   read the authentication parameters.

Which way to deploy, depends on what protocol you intend to use to
access the repos, and what protocol Bitbucket servers actually support.

Note that in the cases (a) and (c) you store the password as plain text
(in the former case the SSH key file is itself "the password", and in
the latter, the password is stored in the file in clear text), so you
have as tight permissions on them as possible.
In the case (b) you're assumed to script Git invocations so that they
receive the password, and this means that password is, again, should be
stored somewhere (right in the text of the script or read by it from
somewhere), and so the same precautions must be applied.

1. http://sourceforge.net/projects/sshpass

-- 
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: pull merge vs a local merge, what's different?

2017-07-21 Thread Konstantin Khomoutov
On Fri, Jul 21, 2017 at 05:46:44AM -0700, Jon Erickson wrote:

> > To start, the user that generated this error was advised to backout the 
> > resulting munge and use a standard merge to fix his problems.  Following 
> > standard merging practices fixed his problems but his original approach had 
> > been nagging at me.  This user was using git pull to merge from master to 
> > his personal development branch.  Here are the steps he was performing 
> > and the resulting pop:
> >
> > git checkout -b ticket/1976 origin/master
> >
> > git commit -m 'As requested, renamed files to reflect their type.'
> >
> > git commit -m 'Added convenience alias for commands.'
> >
> > git commit -m 'Modifications to support "use PAW" Banner display.'
> >
> > git pull origin master
> >
> > got the following:
> >
> > error: merge died of signal 11 (SEGV) plus a core file
> >
> Could SEGV mean segmentation fault i.e. out of memory error or am I way 
> off base?  

That's exactly what it means.

But to be honest, SIGSEGV seldom, if ever, means an out-of-memory error,
except when there's a bug in the software so when the C's malloc()
returns NULL -- it does to in the case of out-of-memory, -- that value
is not checked for being valid and is used right 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] Beginner: delete 2 revisions

2017-07-21 Thread Konstantin Khomoutov
On Tue, Jul 11, 2017 at 10:23:12AM -0700, DynV Montrealer wrote:

> I'd like to delete revision 2 & 5 on 
> http://gist.github.com/WilliamCQ/4d734bf3e7c3ab59b08c949f1ab673d7 and have 
> no idea how to proceed by command line and the web interface won't let me 
> do it; it's support assured me it can only be done by command and they 
> won't help with that. Please keep in mind I'm a beginner.
> 
> Thank you kindly for your help
> 
> PS: I'm not sure what's going on but it won't let me post with the 
> following tags: gist, github, delete revision, remove revision, dump 
> revision, clear revision, eradicate revision.

>From what I gather from the description and looking at the linked
resource, you're asking about removing a pair of revisions from a
Github's "gist" -- which is online (that is, web-based) collaborative
facility for editing text.  It has nothing to do with Git, which is a
VCS and has nothing to do with Github.

Please try reaching for Github's help facilities:
https://help.github.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] Re: Repository corruption ...

2017-07-21 Thread Konstantin Khomoutov
On Wed, Jul 19, 2017 at 10:32:38PM -0700, Deepti Dua wrote:

> i am still facing error after changing permission
> 
> nitialized empty Git repository in /home/sushmitha/RBTool/test/lte_epc/.git/
> cm_ltepc@gurux's password:
> error: pack-objects died of signal 9
> error: git upload-pack: git-pack-objects died with error.
> fatal: git upload-pack: aborting due to possible repository corruption on 
> the remote side.
> remote: aborting due to possible repository corruption on the remote side.
> 
> fatal: early EOF
> fatal: index-pack failed

>From the git-upload-pack manual page, we get:

| Invoked by 'git fetch-pack', learns what
| objects the other side is missing, and sends them after packing.
| 
| This command is usually not invoked directly by the end user.
| The UI for the protocol is on the 'git fetch-pack' side, and the
| program pair is meant to be used to pull updates from a remote
| repository.  For push operations, see 'git send-pack'.

This means the upload-pack program runs on the remote side, and this
indicates that the problem is in the remote repo.

Try SSH'ing to the remote server and running `git fsck` in that repo.
But first be sure to recursively copy its whole directory to some other
place for backup purposes.

-- 
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] Undocumented reset behavior

2017-04-23 Thread Konstantin Khomoutov
On Sat, 22 Apr 2017 17:57:26 +0100
"Philip Oakley"  wrote:

[...]
> I tried it locally but didn't get what I think you expected. I am on
> git version 2.9.0.windows.1.323.g0305acf (~the last which supports my
> harware).
> 
> What I have / see is
[...]
> So in both these cases, the test simplification appears to result in
> identical output (unless I missed something - could easily happen)

Kudos for such comprehensive testing!

I, personally, have nothing to say on this except for an advice for the
OP for bringing this up on the main Git list (as Igor suggested as
well) -- mentioning all the pointers emerged during the research done
in this thread.

Even if the issue the OP is facing will evoke nothing more than
rehashing of the old argument about the (un)expected semantics, it
might result in documentation patches. ;-)

-- 
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] Undocumented reset behavior

2017-04-22 Thread Konstantin Khomoutov
On Fri, 21 Apr 2017 13:54:30 -0700 (PDT)
vvs  wrote:

> I found out that "git reset --hard" produced different outcome
> depending on current index content, i.e. when there is no entry for a
> file in working tree it actually changed that file. While on the
> contrary, if you use "git reset --mixed" right before that, the file
> won't be touched. This affects make, which thinks that the file was
> changed. Is that intended? I found this behavior somewhat confusing
> and don't see it documented anywhere.

All forms of `git reset`, if not given a specific commit/tree-ish,
take HEAD as the commit/three-ish to take the data from.

That is, your

  git reset --hard

is actually

  git reset --hard HEAD

So if you did not have an entry for a file in the index by the time you
run that command but you do have an entry for that file in the tree
referenced by the commit at HEAD, that file will be "touched", if
needed.

When you do

  git reset --mixed
  git reset --hard

The first command replaces the index with the contents of HEAD
while the second re-does that once again and then updates the working
tree with what's in the HEAD.  I, for one, fail to see how that could
be different from calling `git reset --hard` alone.  So either I fail
to understand your setup or you failed to clearly convey it or maybe
there's a problem with your methodology of observing what was changed.

-- 
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 checkout behavior when you have a tag and a branch with the same name

2017-04-05 Thread Konstantin Khomoutov
On Wed, 5 Apr 2017 00:22:28 -0700 (PDT)
Ferdinando Santacroce  wrote:

[...]
> Supposing there are a branch and a tag called , when I do:
> $ git checkout something
> Git checks out the tag , and not the branch.
> Furthermore, it leaves me in a detached HEAD state.
> 
> So, I'm looking for documentation about this behavior, and I'm
> wondering if there's a way to prefer branches over tags or other
> options I can set.
[...]

This is covered by the gitrevisions manual page
(run `git help revisions`); in particular:

  , e.g. master, heads/master, refs/heads/master
  A symbolic ref name. E.g.  master typically means the commit
  object referenced by refs/heads/master. If you happen to have both
  heads/master and tags/master, you can explicitly say heads/master to
  tell Git which one you mean. When ambiguous, a  is
  disambiguated by taking the first match in the following rules:

  1. If $GIT_DIR/ exists, that is what you mean
 (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,
  MERGE_HEAD and CHERRY_PICK_HEAD);

  2. otherwise, refs/ if it exists;

  3. otherwise, refs/tags/ if it exists;

  4. otherwise, refs/heads/ if it exists;

  5. otherwise, refs/remotes/ if it exists;

  6. otherwise, refs/remotes//HEAD if it exists.

So, if there exists a tag and a branch of the same name, using of an
unadorned ref name would select the tag (rule 3), and if you want to be
precise, use the full name:

  git checkout refs/heads/something

to pick the branch named "something" over the same-named tag.

-- 
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 do you create kerberos authenticated linux script to pull from Apache https enabled git server?

2017-04-04 Thread Konstantin Khomoutov
On Mon, 3 Apr 2017 08:50:03 -0700 (PDT)
ken edward  wrote:

I've replied to your x-post to the main Git list [2] but for some reason
it did not get through, so re-posting here:

> I have my git repositories behind an apache server configured with
> kerberos.
[...]
> BUT, I want to write a script on linux that will also pass the
> kerberos credential to the apache GIT server without having any
> manually intervention. Seems I would create a kerberos keytab for the
> principal and then use that to authenticate kinit supports
> authenticating from a keytab using the -k -t  options,
> but has anyone done this?

Git uses libcurl for HTTP[S] transport; cURL supports ":" as the
user:password spec to imply using SSO when it's told to use NTLM or
GSSAPI (and hence SPNEGO and Kerberos), so first try using something
like http://:@server/path/to/repo.git as your URLs.

See [1] for more info.

1. https://public-inbox.org/git/20170222173936.25016-1-dtur...@twosigma.com/
2. 
https://public-inbox.org/git/002501d2ac96$42a272a0$c7e757e0$@nexbridge.com/T/#t

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

2017-04-04 Thread Konstantin Khomoutov
On Mon, 3 Apr 2017 21:07:02 +0200
Pablo Rodríguez  wrote:

[...]
> My question is simple: what causes a merge conflict?
> 
> I mean, changes in different files are merged fine, since the most
> updated version of each is merged.
> 
> I thought the same happened with different lines (the latter modified
> line is kept in the merged file), but I can’t say for sure after
> experiencing the merge conflicts.
> 
> Could you confirm whether lines are merged independently or whether
> there is always a conflict when one tries to pull a modified file from
> remote in a file that was also modified after latest push in local?

It's a bit trickier.

To begin with, in most cases of simple merging, Git uses the so-called
3-way merging, where it first figures out the point where both sides of
the merge diverged, and compares _differences_ introduced by the sides
since that point.

Now the crucial idea to understand about conflict detection is that of
the "context".  When examining differences, Git takes into account
several lines above and below the detected change, and judging from
this context, it tries to understand whether a particular change
introduced by one side of the merge happens in the same place as
another change introduced by the other side of the merge.  If these
changes happen in different contexts, they are considered
non-conflicting.

As to lines, yes, Git considers changes to happen line-wise.

Another interesting aspect is that one can turn on ignoring of
whitespace changes, so that two lines which only differ in the amount of
whitespace characters would be considered the same.  This is useful for
certain textual formats where _some_ spacing is insignificant -- such as
TeX/LaTeX, Markdown etc (see the `git diff` manual page about the "-b",
"-w" and "--ignore-space-at-eol" command-line options).

-- 
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] Updating a staged file makes it dissappear

2017-03-24 Thread Konstantin Khomoutov
On Thu, 23 Mar 2017 16:31:40 -0700 (PDT)
Igor Djordjevic  wrote:

[...]
> I am still new to Git myself, but as far as I know, one doesn`t
> usually checkout a single file from a remote branch in order to work
> on it - instead, you should either create a local branch out of the
> remote branch (if you don`t have it already), or just fetch/merge
> with your local branch (to update it if you already have it). Then
> you can work on the file as it is, in your local branch, being a part
> of the original commit and following the original history, eventually
> making a commit on the local branch and doing a push to update the
> remote branch with your changes.

Checking out individual file or files into the working tree from a
commit different from HEAD is perfectly legal for situations like
answering a question "whether the (currently buggy) state of the project
will be fixed if we compile it with such and such files taken from that
(known to be good) revision?".

Of course it means you'll revert the contents of these files back to
HEAD afterwards.  Or keep just the changes which had apparently fixed
the problem (by, say, running
`git checkout --patch HEAD -- path/to/file` on each of them to get rid
of unwanted changes) etc.

It's even OK to actually _use_ the contents of those files from another
revision (after properly `git add`-ing these changes and committing
them): after all, it does not matter how exactly particular changes
ended up in the files ;-)

I think it all boils down to having proper mental model of how Git
maintains the history, what's in a commit, what a branch is and so on.
This can only be gained through self-education and practice.

Having said that, I'd note that you're absolutely correct in

> one doesn`t usually checkout a single file from a remote branch in
> order to work on it - instead, you should either create a local
> branch out of the remote branch (if you don`t have it already), or
> just fetch/merge with your local branch (to update it if you already
> have it).

This highlights a crucial thing to understand about the model pervasive
through all Git does: it does not consider individual files to be of any
importance and always deals with the state of the whole project being
managed.  For instance, it's impossible to "commit a single file".
Even though there's a shortcut for this -- `git commit ` --
it's just a handy way to do the sequence

  1) Save the index away.
  2) Make it look as HEAD.
  3) `git add` the indicated file(s).
  4) `git commit` the resulting state of the index.
  5) Restore the index back.
  6) Update it with what was `git add`-ed on step (3).

…and thus a "normal" commit, snapshotting the whole project, is
recorded.  In the same venue, it's impossible to push a single file or
fetch a single file's changes, and so on.

Hope this will help the OP to get their Git mental model 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] how to keep a log of changes before committing

2017-03-16 Thread Konstantin Khomoutov
On Thu, 16 Mar 2017 04:40:25 -0700 (PDT)
grandemund...@gmail.com wrote:

> Can the following be done within git.
> 
> Make changes to a project that is not ready to be committed. 
> Have a separate textile to describe. stop working on it for a while.
> When ready to be committed, I copy and paste the textfile in the
> message of the commit.
> 
> Is there a git command that keep track of all the description of the 
> changes. add them all up in the message when I commit.

Yes, you just need to stop thinking in terms of "how would I _not_
commit" ;-)

What you need is the idea is that 1) branches in Git are dirt-cheap,
and 2) you are not required to push a branch anywhere.

So, your workflow for such a case is:

1) Make changes to a project, decide that they are not ready to be
   committed.

   At this point, fork a branch off HEAD:

 $ git checkout -b whatever

   (Put a more sensible name than "whatever".)

   Nothing has happened to your changes yet -- Git had merely recorded
   the fact the HEAD now points at "whatever" and not at the branch
   you had checked out.

   Now add your changes and commit.

2) Check out the original branch:

 $ git checkout -

   Continue working.

3) Now suppose you'd like to continue messing with your "not ready
   to commit" changes.

   Before recording new changes on that "whatever" branch, you need
   to synchronize the state of the project it tracks to the new
   developments which had happened on the branch you forked it off.

   To do this, you need to "rebase" your changes on top of the updated
   "parent" branch.  If that parent branch is called "master", you do:

 $ git checkout whatever
 $ git rebase master

   or in one step:

 $ gir rebase master whatever

   (which would first check "whatever" out and then rebase it on top
   of "master").

   The result of this command is that your "whatever" branch now looks
   just like "master" with your tempoary commits on top.

   Now continue hacking away recording new temporary commits.

   Repeat steps 2 and 3 until your feature is ready to "be committed" --
   as you have already formulated that.

4) When you decide your changes are ready for prime time, you do the
   so-called "squash merge":

 $ git checkout master
 $ git merge --squash whatever
 $ git commit

   The "--squash" option to `git merge` will make the command not record
   a regular merge but:
   - Collapse (squash) all the commits which are on "whatever" compared
 to "master" into a single change.
   - Prepare a commit message which is the concatenation of all the
 commit messages of all the squashed commits.
   - Exit -- allowing you to run `git commit`, edit the generated
 "gross" commit message and proceed.

   Delete the "whatever" branch:

 $ git branch -D whatever

Executive summary ;-)

There's no need to invent anything new to handle the workflow you need:
use a separate branch which you forward-port (rebase) on top of its
"parent" branch before making new changes on it, and when what you were
developing is ready, squash-merge the result into the original 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] Noob question: How can I inspect a file 'added by them'?

2017-02-21 Thread Konstantin Khomoutov
On Mon, 20 Feb 2017 20:42:58 -0800 (PST)
AD S  wrote:

> Both myself and someone else have added the same file and so when
> I've tried to push my file to a remote repo, I get the error `added
> by them: styles.scss`.
> 
> I want to inspect 'their' file to see how it differs from mine. Is
> there a way I can view that file with the command line?

It's possible.

To cite `git help revisions`:

| ::, e.g. :0:README, :README
| A colon, optionally followed by a stage number (0 to 3) and
| a colon, followed by a path, names a blob object in the index at the
| given path. A missing stage number (and the colon that follows it)
| names a stage 0 entry. During a merge, stage 1 is the common ancestor,
| stage 2 is the target branch’s version (typically the current branch),
| and stage 3 is the version from the branch which is being merged.

When a merge conflict happens, the entry in the index for the file with
an active conflict actually points at the several versions of the
content of that file, called "stages".

When you just want to see the contents of a non-conflicting file as
recorded in the index, you do

  git show :path/to/that/file

and that simple ':' actually gets interpreted to mean ":0:" as in

  git show :0:path/to/that/file

The "theirs" version of an index entry which records the state of a
file in conflict is 3, so to see "theirs" version, you do

  git show :3:path/to/that/file

-- 
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: Noob question: In a large company setting, is it normal to spend 3+ hours a day sorting out git issues?

2017-02-13 Thread Konstantin Khomoutov
On Mon, 6 Feb 2017 12:14:54 -0800 (PST)
Hugh Gleaves  wrote:

> I'd like to see a forum is all I mean, the format interaction and
> usability are weak in mailing lists, IRC is ancient and StackOverflow
> is not confined to Git.
> 
> e.g.
> 
> https://forums.asp.net/
> 
> https://social.msdn.microsoft.com/Forums/sqlserver/en-US/home?category=sqlserver
> 
> http://www.linuxforums.org/forum/
> 
> These are just better UIs and more friendly that these other
> character oriented systems - IMHO

That's fine until you have 2-3 forums to participate on.

I'm subscibed to more than a dozen of mailing lists, and _then_ it's
apparent that forums would just not scale to that degree for me --
emails are way simpler to wield then: you get notification of someone's
post right into your inbox and then you just reply to it right away.
No need to log into some (usually crappy, and -- which is worse --
different for different forums) web interface to respond, you just do
that.  All sensible MUAs show you threads you're participating in using
nice tree views with read/unread state of messages.

And as to "accessible" interfaces for asking about Git, just check out
the Git tag at SO [1] -- there are gazillions of idiotic questions
getting asked and answered each day.  I once get bored and answered
there a question titled "How to log first 10 in Git?" -- a question,
an answer to it could be obtained by searching in the `git log` manual
page for some 30 seconds, -- and guess what? it became the most upvoted
answer among all my answers on SO :-)

Your passage about character-oriented systems, I cannot comprehend --
aren't we exchange text messages no matter whether this happens on a
mailing list or a web-based forum?

1. https://stackoverflow.com/questions/tagged/git

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

2017-02-08 Thread Konstantin Khomoutov
On Wed, 8 Feb 2017 12:17:37 +0100
Cecil Westerhof  wrote:

> I had a talk yesterday with a company where they are using
> Subversion. The reason is that all there suppliers use Subversion. I
> understood it should be quit easy to communicate from Git with
> Subversion repositories. Is that true? Does anyone has any
> experiences to share?

Git has Subversion bridge which appears to work OK for most cases.

Still, it should be understood that both systems have rather
drastically different world views on certain concepts of a VC system,
so it's possible to reach certain corner cases IMO.

Still, you can use `git svn` personally to work on source code using
Git and push to Subversion server (and get updates from there).
That's basically what this bridge was invented for anyway.

> Also, how can I ‘sell’ the switch from Subversion to Git? I like Git
> much better as Subversion, but I am afraid that is not really useful
> for persuasion. ;-)

Please be cold-headed on these matters.
While Git indeed appeals to mid- to highly-skilled *developers,* there
are other things to consider: lower-than-middle-skilled developers
which constiture the largest percent of many shops involving software
development and management which has concerns largely orthogonal to
ease of development.  I mean people in this camp will have hard time
understanding why `git add --patch` and `git log -S` are cool, and the
management will be obsessed with the idea that you control who can
access which *part* of a repository based on the pathnames of files
kept in it.

Please read [2].  It shows its age (Git now works rather well on
Windows, and centralized turn-key solutions for Git do exist -- if not
Windows-specific) but it captures the essense of what I'm talking about
pretty well.

Also consider that should you actually succeed in switching be prepared
to serve as a "Git go-to guy" for that shop for an indefinite amount of
time, and this means both teaching the folks and dealing with things
like the scenario #2 from [3] (I've witnessed such things myself).

All in all, the best strategy for pushing for something over something
entrenched, as usually, appears to be _gradual_ attacks.  That is, form
a group of supporters, and manage one simple project in Git.  If that
succeeds, you'll have hard facts to present before the management and
the other devs.

1. https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
2. http://blog.red-bean.com/sussman/?p=79
3. https://randyfay.com/content/avoiding-git-disasters-gory-story

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


  1   2   3   4   5   6   7   8   9   10   >