Re: Any way to make git-log to enumerate commits?

[Konstantin Khomoutov]

On Thu, Dec 06, 2018 at 09:31:36AM +0900, Junio C Hamano wrote:

> >> It would be great if git-log has a formatting option to insert an
> >> index of the current commit since HEAD.
> >> 
> >> It would allow after quitting the git-log to immediately fire up "git
> >> rebase -i HEAD~index" instead of "git rebase -i
> >> go-copy-paste-this-long-number-id".
> >
> > This may have little sense in a general case as the history maintained
> > by Git is a graph, not a single line. Hence your prospective approach
> > would only work for cases like `git log` called with the
> > "--first-parent" command-line option.
> 
> I do not see why the "name each rev relative to HEAD" formatting
> option cannot produce HEAD^2~2 etc.
> 
> It would be similar to "git log | git name-rev --stdin" but I do not
> offhand recall if we had a way to tell name-rev to use only HEAD as
> the anchoring point.

My reading was that the OP explicitly wanted to just glance at a single
integer number and use it right away in a subsequent rebase command.

I mean, use one's own short memory instead of copying and pasting.

The way I decided to format the reference in my sketch script — using
HEAD~ — is just a byproduct of the fact I was aware both of the
"gitrevisions" manual page and the fact `git name-rev` exists (though I
regretfully was not aware it's able to process a stream of `git log`).

Hence while getting fancy names for revisions would be technically
correct but less error-prone for retyping from memory ;-)

Re: Any way to make git-log to enumerate commits?

[Konstantin Khomoutov]

On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:

> It would be great if git-log has a formatting option to insert an
> index of the current commit since HEAD.
> 
> It would allow after quitting the git-log to immediately fire up "git
> rebase -i HEAD~index" instead of "git rebase -i
> go-copy-paste-this-long-number-id".

This may have little sense in a general case as the history maintained
by Git is a graph, not a single line. Hence your prospective approach
would only work for cases like `git log` called with the
"--first-parent" command-line option.

Still, for a simple approach you may code it right away yourself.
Say, let's create an alias:

  $ git config alias.foo '!git log "$@" --pretty=oneline --source | {
  n=0;
  while read sha ref rest; do
printf "%s\t%s~%s\t%s\n" "$sha" "$ref" $n "$rest"
n=$((n+1))
  done
}'

Now calling `git foo --abbrev=commit` would output something like

9be8e297dHEAD~7   Frobincated fizzle

where "7" is what you're looking for.

A more roubst solution may need to use the `git rev-list` command.

Re: git bash lunching error

[Konstantin Khomoutov]

On Mon, Nov 26, 2018 at 08:32:27PM +0530, Chandra Shekhar wrote:

> cess: Resource temporarily unavailable (-1).
> DLL rebasing may be required; see 'rebaseall / rebase --help'.

This  ?

Please do not post screenshots, post text.
Also please copy and paste correctly when you do this.

Re: git overwriting local ignored files?

[Konstantin Khomoutov]

On Sat, Nov 24, 2018 at 05:57:24PM +0300, Konstantin Khomoutov wrote:
> On Sat, Nov 24, 2018 at 09:37:06AM -0500, David Mandelberg wrote:
> 
> > > > It seems that git is overwriting my local files on merge if they're in
> > > > .gitignore.
> [...]
> > > The .gitignore file is to list "ignored and expendable" class of
> > > files; there is no "ignored but precious class" in Git.
> > Ok. Would a patch be welcome? I have three ideas for how to implement it,
> > and I'm not sure which is better.
> [...]
> 
> You might want to first investigate this recent thread [1] which AFAIK
> was dedicated to exactly this problem.

Well, actually the thread is old, but its continuation [2] is recent.
The crux is that it discusses certain approaches to solve the apparent
problem and patches to do that.

1. https://public-inbox.org/git/4c6a1c5b.4030...@workspacewhiz.com/
2. https://public-inbox.org/git/871s8qdzph@evledraar.gmail.com/

Re: git overwriting local ignored files?

[Konstantin Khomoutov]

On Sat, Nov 24, 2018 at 09:37:06AM -0500, David Mandelberg wrote:

> > > It seems that git is overwriting my local files on merge if they're in
> > > .gitignore.
[...]
> > The .gitignore file is to list "ignored and expendable" class of
> > files; there is no "ignored but precious class" in Git.
> Ok. Would a patch be welcome? I have three ideas for how to implement it,
> and I'm not sure which is better.
[...]

You might want to first investigate this recent thread [1] which AFAIK
was dedicated to exactly this problem.

1. https://public-inbox.org/git/4c6a1c5b.4030...@workspacewhiz.com/

Re: Fwd: "show-ignore" problem after svn-git clone

[Konstantin Khomoutov]

On Wed, Nov 21, 2018 at 08:37:03AM -0500, Jamie Jackson wrote:

> I'm brand new to svn-git and I'm having a problem right out of the
> gate. I suspect I need a different ID, but I have no clue how to get
> it.
> 
> Here's the failed attempt:
> https://gist.github.com/jamiejackson/57e90302802f4990b36dfe28c3c71d13

Please post the content supposedly available at that link in your mail
message, inline.  Otherwise it's impossibly to sensibly comment on it.

Re: Add issue management within git

[Konstantin Khomoutov]

On Sun, Nov 11, 2018 at 11:50:00PM +0100, Martin Delille wrote:

> This would be awesome to handle issue directly with git: Having an
> offline version of the issues synced to the gitlab/github issues.  A
> lot of work is done on the issues and it is lost when migrating from
> one service to the other.  Beside we don’t always have a good internet
> connection.  There is already a kind of integration between commit
> message fixing issue automatically when merged in the master branch
> (with “fix #143’).

[1] is the last discussion (of many) happened on this list on this
topic. Please start there. It also contains pointers to past discussions
and past work done on that front.

1. 
https://public-inbox.org/git/CACSZ0Pwzs2e7E5RUEPDcEUsa=inzCyBAptU7YaCUw+5=mut...@mail.gmail.com/

Re: Add issue management within git

[Konstantin Khomoutov]

On Mon, Nov 12, 2018 at 09:35:31AM +0800, yan ke wrote:

> > This would be awesome to handle issue directly with git:
> > Having an offline version of the issues synced to the gitlab/github issues.
> > A lot of work is done on the issues and it is lost when migrating
> > from one service to the other.
> > Beside we don’t always have a good internet connection.
> > There is already a kind of integration between commit message fixing
> > issue automatically when merged in the master branch (with “fix
> > #143’).
>Very very agree, now it is very difficult to find a solution when
> has some problem such build problem an so on! The mail-list is good to
> send patch es, but is it not suitable for problem track or problem
> solution search!
>Now the Github or Gitlab is good to track issues, suggest to open
> the git issue track!

Please don't hijack the discussion: the original poster did not question
the workflow adopted by the Git project itself but rather asked about
what is colloquially called "distributed bug tracker", and wanted to
have one integrated with (or into) Git. That is completely orthogonal
story.

As to searching for Git issues / problem solutions - I'd recommend using
the search on the main Git mailing list archive [1] and the issue
tracker of the Git for Windows project [2].

The communities around Git also include the "Git Users" low-volume
mailing list [3] (also perfectly searcheable), and the "git" tag at
StackOverflow [4].

1. https://public-inbox.org/git/
2. https://github.com/git-for-windows/git/issues
3. https://groups.google.com/forum/#!forum/git-users
4. https://stackoverflow.com/questions/tagged/git

Re: Using Git for applications other than code development

[Konstantin Khomoutov]

On Wed, Jul 25, 2018 at 01:02:16PM +, David Hind wrote:

> I work for a company that is looking to adopt VCS and I like sound of
> Git (although I have no experience of using VCS). My question is,
> everything seems to be directed towards code developers. Can I use Git
> to do revision control for other types of design document? For example
> electrical circuit designs, circuit PCB designs etc.?

In addition to what Randall said (I would affirm he has presented a
comprehensive and correct picture), I'd make one minor note: Git is a
distributed VCS, and this requires certain pondering.

Even though you will almost certainly have one central (also
colloquially called "rendez-vouz") repository where everyone pushes
their changes to, and fetches them from, Git allows recording any number
of so-called "commits" — atomic, from a logical standpoint, changes to
the project — before sharing them with the rest of the team.

For software development, this _is_ blessing; for other kinds of
development it may be not so good — with the need to somehow resolve
possible conflicts in series of changes made in parallel by multiple
developers to the same content being supposedly the main impediment.
With software development it's simple: it's still done by writing
textual files (even tools which generate code automatically tend to
generate something textual these days), and conflicts in textual files
are relatively easy to represent (even without resorting to specialized
tools). Now, say, let's look at gamedev where a part of the team are
artists which work on "assets" — such as 3D-models and textures.
Two conflicting changes in the same texture are harder to reconcile.

Some (most?) centralized VCSes (as opposed to distibuted) support
explicit "locking" of certain files - which works like sort of claim
"I'm working on this file, don't touch it". Git does not have locking,
and if you think it may benefit your workflow then may be other options
might suite you better.

Re: Q: Ignore ./foo, but not script/foo

[Konstantin Khomoutov]

On Thu, Jul 19, 2018 at 07:06:57PM +1000, Timothy Rice wrote:

[...]
> Most people do put "." in their PATH for convenience
[...]

IMO this is a gross overstatement: personally, I know of no person using
a Unix-like operation system who does this.

Re: FW: Merging in Git with Branches

[Konstantin Khomoutov]

On Mon, Mar 26, 2018 at 10:12:04AM +, shirlin.jos...@bt.com 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] as well.

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

Re: get commit ID from a tree object ID

[Konstantin Khomoutov]

On Sat, Mar 17, 2018 at 01:17:12PM +0100, Michal Novotny wrote:

> let's say I have made an annotated tag on a certain treeish:
> 
> $ git tag -a -m msg tagname HEAD:
> 
> Now, I can try to see the content of the tag:
> 
> $ git tag -v tagname
> object 42a1c36553a50ceae2f75ffc4b1446c6c393eae7
> type tree
> tag tagname
> tagger clime  1521288727 +0100
> 
> msg
> error: no signature found
> 
> 
> Can I use that object ID 42a1c36553a50ceae2f75ffc4b1446c6c393eae7 to
> get back to a particular commit from which the tag was created? The
> reason is that I would eventually like to checkout that commit.

In general, you can't, and that's because there can be any number of
commits referencing that tree. A typical case is a tree object
representing a subdirectory of your project which changes rarily, if
ever - in this case, each commit which includes the same state of this
subdirectory will refer the same tree object.

Another point to consider is that the commit itself only refers to a
single tree object -- that one which records the state of the top-level
project directory, and it usually refers to other three objects which
may, in turn, refer to others and so on - all the way down.

So actually a generic approach to what you need is a full scan of all
the commits in the repository with recursive traversing of the hierarchy
of trees of each of them (via `git ls-tree`) and looking for the SHA-1
name of the reference tree object.  As you can see, this is not going to
be fast on repos of realistic size.

Re: Help...!

[Konstantin Khomoutov]

On Fri, Mar 16, 2018 at 07:38:07PM +0530, JYOTIK MAYUR wrote:

> i am working on a project that is git hosting website like GitHub. I
> am a student so i don't know much on how to make a website like GitHub
> so could please tell me what can be the appropriate steps to make a
> website like that(mostly the server part).

Sure, just study the code of the following projects:

- Go: https://gitea.io/
- C#: https://bonobogitserver.com/
- Java: http://gitblit.com/

Still, please note that this list deals with the development of Git,
so your question clearly is off-topic here, so please refrain from
asking such questions here.

You could try https://www.reddit.com/r/git/ for a start.

Re: Git should preserve modification times at least on request

[Konstantin Khomoutov]

On Wed, Feb 21, 2018 at 11:14:20PM +0100, Peter Backes wrote:

[...]
> atime, in contrast, was clearly one of the rather nonsensical 
> innovations of UNIX: Do one write to the disk for each read from the 
> disk. C'mon, really? It would have been a lot more reasonable to simply 
> provide a generic way for tracing read() system calls instead; then 
> userspace could decide what to do with that information and which of it 
> is useful and should be kept and perhaps stored on disk. Now we have 
> this ugly hack called relatime to deal with the problem.
[...]

IIUC, the purpose of atime can be more apparent if you consider it in
the context of the time it appeared: the systems were multi-user but the
disks were small, so a question "what files are lying there but appear
to be unused" was rather sensical to ask as such files could be found,
reported and then considered for deletion of moving off rotating media
to tapes etc.

Re: Is the -w option for git blame bugged?

[Konstantin Khomoutov]

On Fri, Feb 16, 2018 at 05:47:41PM +0800, hgfds jhgfds wrote:

> I recently asked a question on stackoverflow regarding what seemed to
> be erroneous output from git blame when the -w option is specified.
> However, no one answered my question, so I decided to ask here
> instead.
> 
> The question is available at
> https://stackoverflow.com/questions/48808281/git-blame-ignore-whitespace-option-bugged
> 
> Hope someone can help to shed light on this issue soon.

This is indeed the correct place to ask such questions.
Still, the next time please literally ask the question - inclusing its
full text - rather than dropping a link: few people bother do to that,
and even fewer of them have an SO account to actually answer it.
So it's both just basic netiquette and increasing the circle of the
potentional helpers ;-)

In order to remove the churn, I've copied and pasted your question here;
hope you have no issues with me doing this.

8<
Based on my understanding, the command `git blame` is supposed to show, for
each line in a file, the author and the commit in which the line was last
modified.  So for example, if I run

git blame -- ""

and get the following output for line 5:

106b77db (Walrus 2016-03-24 10:01:36 +0800   5) .root {

it means the line

.root {

originated from the author Walrus in the commit 106b77db.
In other words, if I inspect the patch produced by 106b77db using
`git show -p 106b77db`, I would expect the line

+.root {

to show up in the diff. Indeed, this is the case.

Snippet from 106b77db's diff for :

 /* JavaFX CSS - Leave this comment until you have at least create one rule 
  which uses -fx-Property */
+.root {
+   -fx-background-color: transparent;
+}
+

Now, when I run

git blame -w -- ""

(the -w option ignores whitespace changes, i.e. traces each line backwards in
time to find the last author which introduced non-whitespace changes to that
line), I now get the following output for line 5:

b6a6e8a2 (Walrus 2016-03-31 23:32:50 +0800   5) .root {

However, when I inspect the patch for b6a6e8a2 using

git show -p b6a6e8a2

the diff shows

.root {

rather than

+.root {

as expected.

Snippet from b6a6e8a2's diff for :

+
+/* setting window to be transparent */
 .root {
-fx-background-color: transparent;
-}
-

Has Git given me erroneous output, because according to the diff, the line
.root { was not modified at all in the commit b6a6e8a2?

I am using Git 2.13.3.windows.1.

EDIT: the repository is https://github.com/cs2103jan2016-f14-2j/main,
and the file is JimplePlanner/src/application.css.
After upgrading to Git 2.16.1.windows.4, the issue still persists.
8<

Re: Uninstall Git

[Konstantin Khomoutov]

On Thu, Feb 15, 2018 at 01:01:14PM +0100, Jan Nguyen wrote:

> I would like to ask how can I uninstall Git?

Please follow the answers given to this question at
https://apple.stackexchange.com/search?q=%5Bgit%5D+uninstall

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

[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

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

[Konstantin Khomoutov]

On Sun, Aug 06, 2017 at 01:16:46PM +0200, Lars Schneider wrote:

[...]
> >  * It is now possible to switch between Secure Channel and OpenSSL for
> >Git's HTTPS transport by setting the http.sslBackend config
> >variable to "openssl" or "schannel"; This is now also the method
> >used by the installer (rather than copying libcurl-4.dll files
> >around).
> 
> Does anyone have a pros/cons list for this option? AFAIK OpenSSL is still
> the default in the GfW installer and I wonder why. My gut feeling would be to 
> go with the SSL implementation shipped with the OS. However, I don't have 
> enough 
> knowledge of either implementation to make an assessment.

One fact which immediately comes to mind is that both frameworks use
different sets of certificates (schannel uses the system's one, and
OpenSSL uses what gets shipped with it).  Another fact is that they
might have different sets or protocols implemented and/or enabled by
default.  Hence switching schannel on for people who used OpenSSL might
break things for them.

Re: Binary files

[Konstantin Khomoutov]

On Thu, Jul 20, 2017 at 10:41:48AM +0300, Volodymyr Sendetskyi wrote:

> It is known, that git handles badly storing binary files in its
> repositories at all.
[...]
> So the question is: why not implementing some feature, that would
> somehow handle this problem?
[...]

Have you examined git-lfs and git-annex?
(Actually, there are/were more solutions [1] but these two appear to be
the most used novadays.)

Such solutions allow one to use Git for what it does best and defer
handling of big files (or files for which lock-modify-unlock works better
than the usual modify-merge) to a specialized solution.

1. http://blog.deveo.com/storing-large-binary-files-in-git-repositories/

Re: Should "head" also work for "HEAD" on case-insensitive FS?

[Konstantin Khomoutov]

On Tue, Jul 04, 2017 at 12:00:49AM +0200, Ævar Arnfjörð Bjarmason wrote:

> I don't have a OSX box, but was helping a co-worker over Jabber the
> other day, and he pasted something like:
> 
> $ git merge-base github/master head
> 
> Which didn't work for me, and I thought he had a local "head" branch
> until realizing that of course we were just resolving HEAD on the FS.
> 
> Has this come up before? I think it makes sense to warn/error about
> these magic /HEAD/ revisions if they're not upper-case.
> 
> This is likely unintentional and purely some emergent effect of how it's
> implemented, and leads to unportable git invocations.

JFTR this is one common case of confusion on Windows as well.
To the point that I saw people purposedly using "head" on StackOverflow
questions.  That is, they appear to think (for some reason) that
branches in Git have case-insensitive names and prefer to spell "head"
since it (supposedly) easier to type.

I don't know what to do about it.
Ideally we'd just have a way to perform a final check on the file into
which a ref name was resolved to see its "real" name but I don't know
whether all popular filesystems are case preserving (HFS+ and NTFS are,
IIRC) and even if they are, whether the appropriate platform-specific
APIs exists to perform such a check.

Re: Bug with automated processing of git status results

[Konstantin Khomoutov]

On Fri, Jun 30, 2017 at 09:00:14AM +0300, Сергей Шестаков wrote:

> I am trying to make an automated processing of "git status" results.
> I execute the command
> 
> git status -z -uno
> 
> I expect that it has stable output format. However, it still can print
> warnings like
> 
> warning: CRLF will be replaced by LF in somefile.xml
> 
> I understand that we can turn off core.safecrlf, but it's
> inconvinient. It would be better if "git status" command had an
> optional parameter that disables any other output besides changed
> files.

The `git status` command supposedly writes their "regular" data to its
standard output while warnings go to its standard error stream.
Is this not the case?

Re: [BUG] GITK don't show unstaged changes

[Konstantin Khomoutov]

On Fri, Jun 16, 2017 at 11:27:39AM +, Clébio C. Felix wrote:

>>> Details:  https://github.com/git-for-windows/git/issues/1203 
>>> 
>>> Version with bug: 2.13.1
>>> Normal: 2.13.0
>> 
>> Attached are the pictures for those who doesn't want to browse that bug
>> and dig them up.
>> 
>> Basically, the idea is that Gitk in 2.13.1 won't show that "Local
>> uncommitted changes blah blah ..." entry above the one representing the
>> tip commit even though the `git status` command shows them.
> If this is an intentional change and not a bug, then gitk has become
> less useful to me, since I've always used it to do a quick review
> before committing. It's easier than using bash. Sad.

Hi!

Well, my message with your pic displaying the bug seemingly failed to
come through the filters of the list hosting software.

But while we're on it -- please, when you're asked to report your
problem somewhere else don't just drop a link to a prior discussion:
chances are very high, most of those who would otherwise pay attention
to your problem will simply skim over and ignore it whatsoever.

I tried to correct this without much fuss but it seems like that did not
quite work out ;-)

Re: Feature Request: Show status of the stash in git status command

[Konstantin Khomoutov]

On Mon, Jun 12, 2017 at 11:42:44PM -0400, liam Beguin wrote:

[...]
>> Conceptually, the contents of the stash are *not* commits, even
>> though the implementation happens to use a commit to represent each
>> stash entry.  Perhaps "has %d entry/entries" is an improvement, but
>> a quick scanning of an early part of "git stash --help" tells me
>> that
> 
> what's different between a stash and a commit? 

The same that exists between an interface and a concrete implementation
in a programming language.

"A stash entry" is a concept which is defined to keep explicitly
recorded untracked files and which can be applied, shown and deleted
from the stash bag (well, you can create a branch off it as well).

The fact a stash entry is a merge commit of two synthetic commits is an
implementation detail.  It can be very useful at times for power users,
but regular Git users need not be concerned with this.

Another fact worth reiterating that what the UI displays to the user is
better to match what the user reads in the docs. ;-)

Re: Git "Keeping Original Dates"

[Konstantin Khomoutov]

On Mon, Jun 05, 2017 at 05:14:01PM -0400, Hector Santos wrote:
> I'm implementing GIT.  If there an option or compile/version that "keep"
> file timestamps?

Just in case you've missed it, there's an explanation of why Git behaves
the way it does in this regard [1].

1.  
https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F

Re: Git Error Message

[Konstantin Khomoutov]

On Mon, Jun 05, 2017 at 02:54:55PM +0100, Philip Oakley wrote:

> > > I have installed the Git software and upon trying to update a
> > > repository by the "open recent repository" link and am unable to
> > > access the menu-or anything-from there.  Instead a window pops up with
> > > the following error message:
> > > 
> > > "\usage C:\Program Files\Git\mingw64/libexec/git-core\git-GUI[
> > > {blame|browser|citool}]
> 
> Can you show the full error message / dialog window?
> 
> With a little bit of staring you will see the line numbers and a few clues
> about the stack history for the error (i.e. line number and variable)
> 
> > > Can you please tell me what this error message means and how to fix
> > > the issue?  Thank you!
> > 
> > A shot in the dark until someone with access to Windows chimes in (it
> > appears that the "open recent repository" feature of `git gui` is specific
> > to Git for Windows): have you verified that repository actually exists
> > on your filesystem?
> 
> Feature is common but the implementations look slightly different
> 
> https://github.com/git/git/blob/master/git-gui/lib/choose_repository.tcl#L123
> $opts insert end [mc "Open Existing Repository"] link_open
> 
> https://github.com/git-for-windows/git/blob/master/git-gui/lib/choose_repository.tcl#L152
> -text [mc "Open Recent Repository:"]
> 
> I'm not sure how the differences are created between the two source codes.
> 
> The nominal upstream by Pat Thoyts has the same as the git.git version
> https://github.com/patthoyts/git-gui/blob/master/lib/choose_repository.tcl#L123

Heh, somehow I've got an impression the GfW's version of `git gui` was
taught to look in the registry for the recent folders and then pick
those  which have ".git" directory located inside or whose names end
in ".git" ;-)

Re: Git Error Message

[Konstantin Khomoutov]

On Sat, Jun 03, 2017 at 01:13:05AM -0700, christienne shultz wrote:

> I have installed the Git software and upon trying to update a
> repository by the "open recent repository" link and am unable to
> access the menu-or anything-from there.  Instead a window pops up with
> the following error message:
> 
> "\usage C:\Program Files\Git\mingw64/libexec/git-core\git-GUI[
> {blame|browser|citool}]
> 
> Can you please tell me what this error message means and how to fix
> the issue?  Thank you!

A shot in the dark until someone with access to Windows chimes in (it
appears that the "open recent repository" feature of `git gui` is specific
to Git for Windows): have you verified that repository actually exists
on your filesystem?

Another interesting question is whether the pathname of that repository
includes space characters which could in principle confuse `git gui`.

Re: How to avoid "Please tell me who you are..."?

[Konstantin Khomoutov]

On Fri, Jun 02, 2017 at 02:02:22AM -0400, Jeffrey Walton wrote:

> I'm working on a test machine. It mostly needs to be a clone of
> upstream. On occasion it needs to test a particular commit.
> 
> When I attempt to test a commit it produces:
> 
> $ git cherry-pick eb3b27a6a543
> 
> *** Please tell me who you are.
[...]
> This is a nameless test account, so there is no information to provide.
> 
> How do I tell Git to ignore these checks?
[...]
> Well, they don't exist so there's nothing to set.
> 
> The machine below its a CubieBoard used for testing. I remote into it
> with test@. As a matter of policy, no check-ins occur on it. Other
> than the password database and authroized_keys file, there is no
> information on it to be lost or stolen.

`git cherry-pick` wants to record a commit.  A commit in Git always
possess the information on "the committer" -- whoever recorded the
commit (it might be distinct from the commit author, as is the case with
cherry-picking).  There's no way to not set the committer.

I envision two ways to get around this situation:

1) Patch the ~/.whatevershellrc of your test account to set this
   information by setting and exporting the GIT_AUTHOR_NAME and
   GIT_AUTHOR_EMAIL env. variables (and may be others -- see the
   "git" manual page; run `git help git`).
   
   May be even add it in /etc/skel to make all accounts create inherit
   it.

2) Set these parameters in the repository you're working with.

   While Git suggests you to pass "--global" to the `git config`
   invocations, it's perfectly OK to use "--local" with them (which is
   IIRC the default, if not supplied) to make these settings be recorded
   in the repository's configuration rather than in ~/.gitconfig.

3) Pass these options explicitly to Git invocations or make a shell
   alias which would do so, like with

   function git() {
 command git \
-c user.name='Joe Tester' \
-c user.email=tes...@acme.corp \
"$@"
   }

I'd personally go with (2).

Re: Unable to download Git

[Konstantin Khomoutov]

On Tue, May 30, 2017 at 12:51:14PM +0530, The Intertainer wrote:

> I have been trying to download the '32-bit Git for Windows setup from
> ‘ https://git-scm.com/downloads’  latest versiion i.e. 2.13.0 but just
> cannot.
> 
> It downloadsl about 4-5mb but then says network error followed by
> Failed -Forbidden. I downloaded the file on the chrome browser online
> downloader.

All the links at https://git-scm.com/download/win actually lead to files
hosted by github.com -- you can see for yourself by hovering over the
relevant links there.

So you could possibly bring this problem in some Gitgub help channel.

Still, I've just downloaded 32-bit 2.13.0-6 whatever from there without
any problem, 35.4 MiB.  On the other hand, the Internet is highly
heterogenous structure, and we surely used different channels to
download; most probably this has nothing to do with Github.

Re: Bug report: Corrupt pack file after committing a large file (>4 GB?)

[Konstantin Khomoutov]

On Fri, May 26, 2017 at 01:51:34PM +0800, Yu-Hsuan Chen wrote:

> There is a bug where committing a large file corrupts the pack file in
> Windows. Steps to recreate are:
> 
> 1. git init
> 2. stage and commit a file larger than 4 GB (not entirely sure about this 
> size)
> 3. git checkout -f
> 
> The file checked out is much smaller than the original file size.

For a bug report to be at least marginally useful, please state your Git
version (run "git --version") and the version of your Windows
installation (including whether it's 32- or 64-bit install).

Please also make sure you're really using Git for Windows (that is, you
got it from [1] or [2] and not, say, from Cygwin.

The best course of actions is to download the most recent available
version from the locations mentioned above and verify the problem still
manifests itself.

1. https://git-scm.com/download/win
2. https://git-for-windows.github.io/

Re: Git 2.13 silent install

[Konstantin Khomoutov]

On Mon, May 22, 2017 at 05:41:52PM +0200, Johannes Schindelin wrote:

> > > Just wondering if someone can send me the instructions for an
> > > unattended/silent install for Git 2.13. 
> > 
> > This guide [1] is outdated but should be applicable (see the new
> > installer file [2] and its "[Components]" section for an up-to-date list
> > of components to select).
> > 
> > 1. https://github.com/msysgit/msysgit/wiki/Silent-or-Unattended-Installation
> > 2. 
> > https://github.com/git-for-windows/build-extra/blob/master/installer/install.iss
> 
> Please note that [1] was copy-edited to Git for Windows 2.x' wiki:
> 
> https://github.com/git-for-windows/git/wiki/Silent-or-Unattended-Installation

Very good!

For some reason googling for git+for+windows+silent+install did not turn
up the new page but rather the old one, so I have falsely assumed it got
lost in transit.  Good to know it wasn't :-)

Re: Git 2.13 silent install

[Konstantin Khomoutov]

On Fri, May 12, 2017 at 09:55:04AM -0400, Rabii Elguermouni wrote:

> Just wondering if someone can send me the instructions for an
> unattended/silent install for Git 2.13. 

This guide [1] is outdated but should be applicable (see the new
installer file [2] and its "[Components]" section for an up-to-date list
of components to select).

1. https://github.com/msysgit/msysgit/wiki/Silent-or-Unattended-Installation
2. 
https://github.com/git-for-windows/build-extra/blob/master/installer/install.iss

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

[Konstantin Khomoutov]

On Thu, May 11, 2017 at 10:10:05AM +, Kerry, Richard wrote:

[...]
> > > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)
> > >
> > > if (unmerged_cache()) {
> > > printf_ln(_("You still have unmerged paths in your index.\n"
> > > -   "Did you forget to use 'git add'?"));
> > > +   "You might want to use 'git add' on them."));
> >
> > This case is *not* an "rhetorical question is the most succinct way to 
> > convey
> > the information" situation; I think this rewrite is a definite improvement.
> > "You might want to 'git add' them" may be more succinct, though.
> 
> "You might want to use 'git add' on them." It isn't about what you
> *want* to use, it's what you *need* to use, isn't it?  And I'm not
> happy about "on them".  I'm not sure quite why, but the phrasing seems
> odd.  How about "You might need to use 'git add'.", or "You might need
> to use 'git add' first.", or "'git add' needs to be used to add
> files." ,  or "'git add' needs to be used before any other git command
> may be used.".

Why not just

  You should run `git add` on each file with resolved conflicts to mark
  them as such.

I'm not an English speaker but IMHO this phrasing concentrates on the
essense of the problem.  It's far from being succint, unfortunately.

I also wonder what to do with "deleted by them" state of certain files
which are also "unmerged" but `git add`-ing them would be a wrong thing
to do if we want to accept the upstream's decision to delete the file.
So maybe something like

  You might run `git rm` on a file to accept "deleted by them" for it.

appended to the original hint would be good.

Re: git log --follow after subtree merge

[Konstantin Khomoutov]

On Wed, May 10, 2017 at 02:15:23PM -0500, Samuel Lijin wrote:

> On Wed, May 10, 2017 at 9:46 AM, Jonny Gilchrist
>  wrote:
> > Hi,
> >
> > After doing a subtree merge, using 'git log' and 'git log --follow' on
> > files in the subtree show only the merge commit in which they were
> > added.
> >
> > After reading around I understand that the issue is that git log
> > --follow doesn't track renames that occur during a merge.
> 
> Try git log --follow -M. (You may also want to combine this with -l and/or 
> -C).
> 
> > Has there been any work (or are there any plans) to allow git log
> > --follow to work in this case? I couldn't find anything in the mailing
> > list archives aside from a couple of threads from 2011 explaining the
> > issue.

Please note that technicaly there wasn't any "rename during merging":
the subtree merge took the three object of the tip commit you were
merging and recorded in in the merge commit as appearing under another
tree object -- identifying the directory which was used as the subtree
prefix.  The result is that the merge commit and the commits recorded
after it have the files of the merged-in history under that prefix, but
the merged-in history itself has them "as is".

Since Git does not record renames (that is, the `git mv` command does
not record a rename either -- the file it "moves" merely "reappears" in
the next commit under a different name), there are two solutions to your
problem.  The first one is to use the usual heuristics of rename/copy
detection at the time of the history traversal -- as suggested by
Samuel.

The second one -- if you don't need the merged-in history to be kept
"pristine" -- is to first run a `git filter-branch` command on it to
relocate the files in all the reachable commits it contains under the
same prefix which you have used for subtree merge and then do that
subtree merge.

Of course, that only works if that history is "yours" and the merging is
considered to be a one-off operation (that is, you won't be updating the
original merged-in line of development).

Re: Git allow to unconditionaly remove files on other developer host

[Konstantin Khomoutov]

On Sat, 15 Apr 2017 14:27:00 +0200
Johannes Sixt  wrote:

> > That curious, but git allow to unconditionally delete files on
> > other developer host when he do `git pull`
[...]
> Know that Git regards everything mentioned in .gitignore as
> dispensible; IOW, by mentioning a file in .gitignore you actually
> give permission to remove the file if necessary. Git does not have a
> feature to say "ignore this file, but it is precious".

KES, you might also be interested in this recent thread [1].

1. 
http://public-inbox.org/git/capuvn2u0uos2mt5+4ejj8m0oknk6xwerl6ce2mihfhtues-...@mail.gmail.com/

Re: Git documentation on branching.

[Konstantin Khomoutov]

On Mon, 10 Apr 2017 12:24:47 +0200
Samuel Åslund  wrote:

[...]
> >> One feature with "git branch xyz" and "git checkout xyz" that is
> >> rather obvious if you know them but bit me a little since I did
> >> not, is that uncommitted work in progress is not affected or saved
> >> when switching between branches.
> > [...]
> > But neither is uncommitted work saved anywhere when you do
> > `svn switch` in Subversion which is analogous to `git checkout`.
> >
> > While I do know quite many people expect Git to somehow "preserve"
> > their work when switching branches without having them do anything,
> > I wonder what in Subversion workflow makes you think Git should have
> > had the behaviour you expected?
> 
> svn switch is heavy, thus I usually checked out a new branch in
> another directory. So probably not the Subversion workflow but rather
> _my_ workflow in Subversion.

Yes.  The equivalent thing with Git would be using its `git worktree`
subcommand (which is a stock subcommand since some time, and previously
was available in the form of an external script).  The said command
basically creates another "checkout" -- a working tree and a separate
index -- linked to the original repository.  You can have any number of
such separate work trees, and what's checked out in them is completely
irrelevant to the repository itself (which only keeps commits and the
data they refer to).

Note that since `git worktree` was (is?) sort of a clever hack not
originally envisioned as one of "stock" workflows, its insufficiently
covered by the documentation.  And while it indeed may be useful --
sometimes it's ineed convenient to have two versions of the same
codebase to be checked out side-by-side, -- I'd warn you against
rushing for using `git worktree` as it appears to support what you did
with Subversion: there is another approach to support your mindset
which I'll explain in a moment.

> Either way, your comment about peoples expectations was what I wanted
> to address. Expectation management is the responsibility of the 
> documentation, right?

It's hard to tell -- as Ævar Arnfjörð pointed out: there are two kinds
of documentation: manuals and books / introductory courses.  As was
shown to you, the manual page on `git checkout` explains what it does.
Whether that's clear right away to any newcomer, I cannot say.
Probably not, but if we'd turn that manual page to a book it will lose
its original meaning of being dry and to the point.

I have that problem with manual pages all the time: quite often they
are most useful on some Nth re-reading, where you approach them with
certain working knowledge under your belt -- and suddenly certain
things you read there "click" in your head; you did read them before
but your mind just skimmed over them while having the impression of
grasping the material.

> I find it quite reasonable to choose whether to stash the work in 
> progress myself before checking out another branch, but since I did
> not expect to need to do that I didn't.
> 
> I think that what made me expect Git to handle my uncommitted work is 
> how the documentation talks about making it easy to switch between 
> working on different features, most of the time I do not feel 
> comfortable checking in when a feature is in a broken state and 
> interruptions for quick fixes usually comes in those situations.

That's more complicated that it sounds.
Consider the following things (in no particular order).

Sometimes "carrying your uncommitted work over" to another state of the
codebase is precisely what you'd want to happen, and that's what
`git checkout` does for your.  It even has a specual "I DO REALLY WANT
IT TO HAPPEN" switch, "-m", which makes that command to try to merge
your local modifications into what is about to be checked out if
otherwise your changes would be in conflict with that state.

What's with untracked files?  Sometimes they should be considered part
of the work to be saved away before checking out another state, and
sometimes not (`git stash` has a special switch, "-u" to make it stash
untracked stuff as well).  What would be the default mode?  Think of
it, and supposedly you'll come to a conclusion that either mode Git
could implement would alienate some group of folks. ;-)

Now let's consider the most interesting bit.

People switching from a non-distributed VC system are inherently and
subconsciously afraid of committing anything which "is not ready".
This is definitely a correct mindset with Subversion (which, IIUC,
still does not implement shelving it considered for a long time)
but not with Git.

Here, it's absolutely OK to lump together all the stuff you're
currently working it by `git add`-ing them, `git commit` it all --
usually putting an informal "WIP" prefix in the front of the commit
message to indicate it's work in progress -- and then switch away to
another branch.

When back, you just to `git reset HEAD~1` to move your checked out
branch one commit back and 

Re: Git documentation on branching.

[Konstantin Khomoutov]

On Mon, 10 Apr 2017 08:56:30 +0200
Samuel Åslund  wrote:

> I just started playing around with branching in git.
> I have been using it more or less as Subversion until now.
> 
> One feature with "git branch xyz" and "git checkout xyz" that is
> rather obvious if you know them but bit me a little since I did not,
> is that uncommitted work in progress is not affected or saved when
> switching between branches.
[...]

But neither is uncommitted work saved anywhere when you do
`svn switch` in Subversion which is analogous to `git checkout`.

While I do know quite many people expect Git to somehow "preserve"
their work when switching branches without having them do anything,
I wonder what in Subversion workflow makes you think Git should have
had the behaviour you expected?

Re: ttk error when starting git gui

[Konstantin Khomoutov]

On Fri, 31 Mar 2017 13:29:04 +0200
"Jessie Hernandez"  wrote:

> > On Fri, 31 Mar 2017 09:53:38 +0200
> > "Jessie Hernandez"  wrote:
> >
> > [...]
> >> >> It's possible to have ttk with 8.5 as well (say, here on Debian
> >> >> 8.5 ships with ttk enabled).
> >> >>
> >> >> A proper patch would be
> >> >>
> >> >> -set default_config(gui.usettk) 1
> >> >> +set default_config(gui.usettk) [namespace exists ::ttk]
> >> >>
> >> >> Could you please test it on your system?
> >> >>
> >> >
> >> > Yeah that seems to work.
> >> > Thanks for this.
> >> >
> >> > I have tried it with git 2.12.2
> > [...]
> >> I spoke to soon. :(
> >> It does not work. I forgot to do a install when testing.
> >> Sorry for the confusion.
> >
> > Care to elaborate on the exact error, please?
> >
> 
> The error I get is the following
> 
> Error in startup script: wrong # args: should be "ttk::style theme
> use theme" while executing
> "ttk::style theme use"
> (procedure "ttext" line 4)
> invoked from within
> "ttext $ui_workdir -background white -foreground black \
>   -borderwidth 0 \
>   -width 20 -height 10 \
>   -wrap none \
>   -takefocus 1 -highlightthickness 1\
>   ..."
> (file "/usr/libexec/git-core/git-gui" line 3190)

Too bad: the git-gui relies on the [ttk::style theme use] command --
that is, the two-argument invocation of [ttk::style] -- to return
the theme being currently in use, and this feature was implemented
on 2008-05-27 [1] by Pat Thoyts.

Judging from the output of

  fossil descendants e83b7dd29ddae998f96538584afb518849ac1e2c

the first Tk release to have this change was 8.6b2.

So the proper fix appears to be more involved:

 set default_config(gui.usettk) \
   [expr {[package vcompare [info patchlevel] 8.6b2] >= 0}]

(The slash+newline sequence is not needed -- it's here mostly
for pretty-printing.)

1. http://core.tcl.tk/tk/info/e83b7dd29ddae998

Re: ttk error when starting git gui

[Konstantin Khomoutov]

On Fri, 31 Mar 2017 09:53:38 +0200
"Jessie Hernandez"  wrote:

[...]
> >> It's possible to have ttk with 8.5 as well (say, here on Debian 8.5
> >> ships with ttk enabled).
> >>
> >> A proper patch would be
> >>
> >> -set default_config(gui.usettk) 1
> >> +set default_config(gui.usettk) [namespace exists ::ttk]
> >>
> >> Could you please test it on your system?
> >>
> >
> > Yeah that seems to work.
> > Thanks for this.
> >
> > I have tried it with git 2.12.2
[...]
> I spoke to soon. :(
> It does not work. I forgot to do a install when testing.
> Sorry for the confusion.

Care to elaborate on the exact error, please?

Re: ttk error when starting git gui

[Konstantin Khomoutov]

On Fri, 31 Mar 2017 09:45:03 +0200
"Jessie Hernandez"  wrote:

> >> I also got this problem when I wanted to build and run git 2.10.x.
> >> I have added the following change to git-gui/git-gui.sh
> >>
> >> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> >> index 5bc21b878..5ce59ef94 100755
> >> --- a/git-gui/git-gui.sh
> >> +++ b/git-gui/git-gui.sh
> >> @@ -894,7 +894,7 @@ set default_config(gui.fontui) [font configure
> >> font_ui] set default_config(gui.fontdiff) [font configure
> >> font_diff]
> >>  # TODO: this option should be added to the git-config
> >>  # documentation
> >>  set default_config(gui.maxfilesdisplayed) 5000
> >> -set default_config(gui.usettk) 1
> >> +set default_config(gui.usettk) 0
> >>  set default_config(gui.warndetachedcommit) 1
> >>  set default_config(gui.tabsize) 8
> >>  set font_descs {
> >>
> >> If you guys want I can submit it as a patch.
> >> But i assume that 'fixing' this by disabling the feature is not
> >> really what we want.
> >
> > It's possible to have ttk with 8.5 as well (say, here on Debian 8.5
> > ships with ttk enabled).
> >
> > A proper patch would be
> >
> > -set default_config(gui.usettk) 1
> > +set default_config(gui.usettk) [namespace exists ::ttk]
> >
> > Could you please test it on your system?
> >
> 
> Yeah that seems to work.
> Thanks for this.
> 
> I have tried it with git 2.12.2

Please consider re-posting this as a proper patch, then. ;-)

Re: ttk error when starting git gui

[Konstantin Khomoutov]

On Fri, 31 Mar 2017 08:44:27 +0200
"Jessie Hernandez"  wrote:

[...]
> I also got this problem when I wanted to build and run git 2.10.x.
> I have added the following change to git-gui/git-gui.sh
> 
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index 5bc21b878..5ce59ef94 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
> @@ -894,7 +894,7 @@ set default_config(gui.fontui) [font configure
> font_ui] set default_config(gui.fontdiff) [font configure font_diff]
>  # TODO: this option should be added to the git-config documentation
>  set default_config(gui.maxfilesdisplayed) 5000
> -set default_config(gui.usettk) 1
> +set default_config(gui.usettk) 0
>  set default_config(gui.warndetachedcommit) 1
>  set default_config(gui.tabsize) 8
>  set font_descs {
> 
> 
> If you guys want I can submit it as a patch.
> But i assume that 'fixing' this by disabling the feature is not really
> what we want.

It's possible to have ttk with 8.5 as well (say, here on Debian 8.5
ships with ttk enabled).

A proper patch would be 

-set default_config(gui.usettk) 1
+set default_config(gui.usettk) [namespace exists ::ttk]

Could you please test it on your system?

Re: Git Vendor Support

[Konstantin Khomoutov]

On Fri, 10 Mar 2017 16:13:20 +
"COLLINS, ROGER W GG-12 USAF NASIC/SCPW" 
wrote:

> ALCON,
> 
> Is there is a specific group or vendor backing Git?  As part of our
> internal approval process, our organization requires that we list a
> vendor that provides active support (ie. Patches) for the Git
> software.

As Git is a volunteer-driven free-software project, there are no vendors
behind it.

Looks like you basically have two options to fulfill the requirements
of your organization:

 * Contact the Software Freedom Conservancy [1] which is an official
   body serving as an aegis for Git and a bunch of other F/OSS projects.
   They are not vendor but at least they are a legal entity and are
   able to do law-speak.

 * Sign a contract with any company offerring support for Git or
   its Git-based solutions.  Atlassian might be an option (I don't know
   for sure -- just speculating, and I'm not affiliated with them
   in any regard).

1. https://sfconservancy.org/about/contact/

Re: Partnership with Git

[Konstantin Khomoutov]

On Tue, 21 Feb 2017 13:21:38 +0200
"Nikita Malikov"  wrote:

> My name is Nikita and I'm from Devart https://www.devart.com/.
> I would like to contact someone from executive staff of Git. I would
> be very thankful for some information how to do this or if someone
> contacts me.

Git is a free software volunteer project and as such, it has no
"executive staff" in the sense enterprises put into it.

Can you maybe state your actual goals please?

Say, if you're looking for commercial support, we could possibly
suggests a couple of pointers.

Re: Request re git status

[Konstantin Khomoutov]

On Mon, 6 Feb 2017 22:46:53 -0800
Ron Pero  wrote:

[...]
> Still, one way or another, it was easy to feel tripped up by that and
> some kind of verbal cue could help.
> I wonder if this kind of message would help: Latest fetch: {timestamp}
[...]

Timestamps have little to no sense with regard to histories.

What you should make use of is the concept of "tracking branches".
The basic idea is outlined below.

When you fetch from a named remote, like with

  git fetch origin

Git creates/updates the so-called "remote" branches for that named
remote in your local repository.  They live in a special hierarchy of
branches distinct from your "normal" branches, and you typically refer
to them using short (incomplete in fact) names which include the name
of the remote they came from.

For instance, if the repo known as "origin" to your local one
contains the branches "master", "foo" and "devel" at the time the
command above was run, Git would create remote branches "origin/master",
"origin/foo" and "origin/devel".

The whole "remote branches" thing serves to provide you with sort of
bookmarks to the state of a remote repository it was last seen.

You can't commit your own work on remote branches, and can't push them
either (I'm oversimplifying things now but let's not digress).
That's because they are, well, bookmarks, and they are not "yours" --
as opposed to normal local branches.

Now another thing Git offers is the possibility to "link" any local
branch to any remote branch.  This mechanism is called "tracking".
The remote branch linked to a local branch is then called "an upstream"
for that local branch, and that local branch is said to be tracking
that upstream branch.

Say, if you've just fetched from a remote repository and want to work
on a branch "foo" someone created there, you can do

  git checkout -b foo --track origin/foo

if you have existing local branch which doesn't track any remote branch,
you can call

  git branch --set-upstream-to origin/whatever

when it's checked out to make it track the origin/whatever remote
branch.

Tracking makes many Git commands be extra chatty about the state of the
tracking local branch compared to the state of its upstream branch.
Say, `git status` will tell you how many different commits your local
and its upstream branch have compared to each other -- a clear sign
that you should consider merging or rebasing your local work if you're
about to push it to the upstream branch.

While tracking helps in this case, you must understand that Git is a
DVCS, and "D" in it means "distributed" which, in turn, implies
"disconnected".  You should very well understand, that pushing to a
remote repository is inherently racy in this model.  That is, by the
time your `git fetch origin` completed, the state of the branches it
just fetched might have already changed by someone else's push.
So unless your organization / team employs some policy on pushing (that
is, each push to certain "shared" branches must be discussed first and
receive a go-ahead from everyone) you have to be prepared for your
push being rejected because someone else will have managed to push
faster than you.

What I'm leading you to, is that showing you any sort of "last fetch
time" won't really help anyway.  You just should know the drill:

* Make use of the tracking feature.
* Never use --force with `git push` unless you absolutely positively
  understand what happens and you have discussed this with everyone
  else in the team or whoever is in charge for the project.
* If pushing fails, run `git fetch` and reconcile your local changes
  with whatever changes crept in there into the "upstream" branch,
  re-attempt pushing.  Rinse, repeat, if needed.

You're advised to read at least [1], or -- better -- the whole chapter
on branching (even better just read the whole book).

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

Re: Git: new feature suggestion

[Konstantin Khomoutov]

On Wed, 18 Jan 2017 10:40:52 +
Joao Pinto  wrote:

[...]
> I have seen a lot of Linux developers avoid this re-organization
> operations because they would lose the renamed file history, because
> a new log is created for the new file, even if it is a renamed
> version of itself. I am sending you this e-mail to suggest the
> creation of a new feature in Git: when renamed, a file or folder
> should inherit his parent’s log and a “rename: …” would be
> automatically created or have some kind of pointer to its “old” form
> to make history analysis easier.

Git does not record renames because of its stance that what matters is
code _of the whole project_ as opposed to its location in a particular
file.

Hence with regard to renames Git "works backwards" by detecting them
dynamically while traversing the history (such as with `git log`
etc).  This detection uses certain heuristics which can be controlled
with knobs pointed to by Stefan Beller.

Still, I welcome you to read the sort-of "reference" post by Linus
Torvalds [1] in which he explains the reasoning behind this approach
implemented in Git.  IMO, understanding the reasoning behind the idea
is much better than just mechanically learning how to use it.

The whole thread (esp. Torvalds' replies) is worth reading, but that
particular mail summarizes the whole thing very well.

(The reference link to it used to be [2], but Gmane is not fully
recovered to be able to display it.)

1. http://public-inbox.org/git/pine.lnx.4.58.0504150753440.7...@ppc970.osdl.org/
2. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

Re: [RFH - Tcl/Tk] use of procedure before declaration?

[Konstantin Khomoutov]

On Tue, 17 Jan 2017 12:29:23 +0100 (CET)
Johannes Schindelin  wrote:

> > In
> > https://github.com/git/git/blob/master/git-gui/lib/choose_repository.tcl#L242
> > the procedure `_unset_recentrepo` is called, however the procedure
> > isn't declared until line 248. My reading of the various Tcl
> > tutorials suggest (but not explictly) that this isn't the right way.
> 
> Indeed, calling a procedure before it is declared sounds incorrect.
[...]
> And it is perfectly legitimate to use not-yet-declared procedures in
> other procedures, otherwise recursion would not work.
[...]

Sorry for chiming in too late, but I'd throw a bit of theory in.

Since Tcl is an interpreter (though it automatically compiles certain
stuff to bytecode as it goes through the script, and caches this
representation), everything is interpreted in the normal script order --
top to bottom as we usually see it in a text editor.

That is, there are simply no declaration vs definition: the main script
passed to tclsh / wish is read and interpreted from top to bottom;
as soon as it calls the [source] command, the specified script is read
and interpreted from top to bottom etc; after that the control is back
to the original script and its interpretation continues.

Hence when Tcl sees a command (everything it executes is a command; this
includes stuff like [proc], [foreach] and others, which are syntax in
other languages) it looks up this command in the current list of
commands it knows and this either succeeds or fails.  The built-in
command [proc] defines a new Tcl procedure with the given name, and
registers it in that list of known commands.

So the general rule for user-defined procedures is relatively
straightforward: to call a procedure, the interpreter should have read
and executed its definition before the attempted call.

Re: Creating remote git repository?

[Konstantin Khomoutov]

On Wed, 14 Dec 2016 09:00:42 +0300
essam Ganadily  wrote:

> given that git is an old and mature product i wounder why there is no
> command line (git.exe in windows) way of creating a remote git
> repository?
> 
> "git remote create repo myreponame"
> 
> frankly speaking i know that our friends in the linux kernel project
> never felt the need to create remote repository because they probably
> rarely need that but i guess their merciful hearts could have some
> feeling for the rest of us?

Also asked and answered (by me) over there at git-users [1].

1. https://groups.google.com/d/msg/git-users/twgkOYV6kX4/FED559TPDQAJ

Re: git bash error

[Konstantin Khomoutov]

On Fri, 9 Dec 2016 11:38:55 +0530
"Karamjeet Singh"  wrote:

> Dear git support,
> My app is crashing whenever i launch the git bash tool. I am
> attaching the error log file from the event viewer. Can you please
> let me know what the issue is with it.
> https://www.dropbox.com/sh/mhkmjn8bmh3x1oh/AABUKmhnn-HW2Kv5UVxdckN6a?dl=0

Hi!

Your report misses lots of information required to even approach it:

- What Git version are you using (the fact is: in each next version of
  a software package some bugs get fixed and others might creep in;
  so knowing an exact version is paramount).

- What OS? Version, flavor, architecture (32/64 bit).

- What software package (i.e. where did you get your Git install from)?

>From the term "git bash", I gather you're talking about Git for Windows.
If so, that project has its own bug tracker on Github [1] -- because
it's still a project sort-of separate from the "vanilla" Git due to
the fact it maintains a set of changes not yet in the Git proper, and
they do packaging work, too.

Please use that issue tracker in two steps:

1) Search it for your issue.  Say, remove the "is:open" modifier from
   the search box in the tracker's web interface, put there the words
   "git", "bash" and "crash" and search.  I'm sure you'll get a hefty
   amount of reports.  Please see whether your issue is already
   reported.

2) If yes, and if (and only if) you have additional details about it,
   please summarise them in a comment.  Please try to write that in
   plain English (plain bad non-native English is okay :-)); try not to
   post links to pictures or videos.  They aren't indexed by search
   engines and require the maintainers to switch their context when
   reading your report/comment.  On some platforms (say, w/o proper
   full-blown web browser) they can even be plain hard to even see.

3) If no, write your report there -- by filling the offerred template.

Thanks.

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

Re: GIT Problem/ISSUE

[Konstantin Khomoutov]

On Mon, 14 Nov 2016 16:59:41 +0100
Robert Fellendorf  wrote:

[...]
> Couldn't resolve host 'gitlab.lrz.de'
[...]

So, what happens when you open a console prompt (Click the Start menu
icon, type "cmd" without the double quotes and activate the application
found), type

  ping gitlab.lrz.de

there and hit the Enter key?

Does it successfully sends three network packets or you do get the
same/similar error message about the hostname "gitlab.lrz.de" being not
resolvable?

As it stands, this issue looks completely unrelated to Git -- please
read the Wikipedia page on the Domain Name System (DNS) for a start.

Re: RFE: Discard hunks during `git add -p`

[Konstantin Khomoutov]

On Wed, 2 Nov 2016 14:46:04 +0100 (CET)
Jan Engelhardt  wrote:

> Current version: 2.10.2
> Example workflow:
> 
> * I would do a global substitution across a source tree, e.g. `perl
> -i -pe 's{OLD_FOO\(x\)}{NEW_BAR(x, 0)}' *.c`
> * Using `git add -p`, I would verify each of the substitutions that
> they make sense in their respective locations, and, based on that,
>   answer "y" or "n" to the interactive prompting to stage good hunks.
> * When done with add-p, I would commit the so-staged hunks,
>   and then use `git reset --hard` to discard all changes that were 
>   not acknowledged during add-p.
> 
> Being able to discard hunks (reset working copy to index contents) 
> during add-p would alleviate the (quite broad) hard reset.

Couldn't you just do

  git checkout -- .

after staging your approved changes?

To selectively zap uncommitted changes from your working tree, you could
do

  git checkout --patch -- .


I'm not sure overloading `git add` with a "reverse" action is a good
idea.  I'm actually prefer pragmatism over conceptual purity but I'm
not sure the prospective gain here is clear.

Re: "Purposes, Concepts,Misfits, and a Redesign of Git" (a research paper)

[Konstantin Khomoutov]

On Fri, 30 Sep 2016 19:14:13 +0300
Konstantin Khomoutov <kostix+...@007spb.ru> wrote:

> The "It Will Never Work in Theory" blog has just posted a summary of a
> study which tried to identify shortcomings in the design of Git.
> 
> In the hope it might be interesting, I post this summary here.
> URL: http://neverworkintheory.org/2016/09/30/rethinking-git.html

I think it would be cool if someone among subscribers could post a link
to our discussion thread [2] back onto that page.  Unfortunatrly that
requires a Disqus login which I don't have, so may be someone in
possession of such login could do that? ;-)

2. 
https://public-inbox.org/git/ce42f934-4a94-fa29-cff0-5ebb0f004...@gmail.com/T/#e95875b7940512b432ab2e29b3dd50ca448df9720

Re: Fork Errors

[Konstantin Khomoutov]

On Thu, 6 Oct 2016 14:02:09 +
"Vacha, Brian [USA]"  wrote:

> When starting Git Bash, I receive the following errors:
> 0 [main] bash 18088 fork: child 14072 - died waiting for dll loading,
> errno 11 bash: fork: retry: No child processes
> 1190419 [main] bash 18088 fork: child 8744 - died waiting for dll
> loading, errno 11 bash: fork: retry: No child processes
> 3343518 [main] bash 18088 fork: child 12324 - died waiting for dll
> loading, errno 11 bash: fork: retry: No child processes
> 7480858 [main] bash 18088 fork: child 17008 - died waiting for dll
> loading, errno 11 bash: fork: retry: No child processes
> 15635036 [main] bash 18088 fork: child 8108 - died waiting for dll
> loading, errno 11 bash: fork: Resource temporarily unavailable
> bash-4.3$
> 
> My connection is great at 72 Mbps download and 93 Mbps upload.  I
> don't receive other errors so it appears to be a Git Bash issue to me.

Have you tried searching through Git for Windows bugtracker [1] for
your problem.  I'm pretty sure it was recently discussed there.
The issue #776 [2] looks like the one you're experiencing.

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

"Purposes, Concepts,Misfits, and a Redesign of Git" (a research paper)

[Konstantin Khomoutov]

The "It Will Never Work in Theory" blog has just posted a summary of a
study which tried to identify shortcomings in the design of Git.

In the hope it might be interesting, I post this summary here.
URL: http://neverworkintheory.org/2016/09/30/rethinking-git.html

The except from that resource written by Greg Wilson, the blog author:
>8
Santiago Perez De Rosso and Daniel Jackson: "[Purposes, Concepts,
Misfits, and a Redesign of Git]
(http://people.csail.mit.edu/sperezde/pre-print-oopsla16.pdf)", _SPLASH
2016_. 

> Git is a widely used version control system that is powerful but
> complicated. Its complexity may not be an inevitable consequence of
> its power but rather evidence of flaws in its design. To explore this
> hypothesis, we analyzed the design of Git using a theory that
> identifies concepts, purposes, and misfits. Some well-known
> difficulties with Git are described, and explained as misfits in
> which underlying concepts fail to meet their intended purpose. Based
> on this analysis, we designed a reworking of Git (called Gitless)
> that attempts to remedy these flaws. 
> 
> To correlate misfits with issues reported by users, we conducted a
> study of Stack Overflow questions. And to determine whether users
> experienced fewer complications using Gitless in place of Git, we
> conducted a small user study. Results suggest our approach can be
> profitable in identifying, analyzing, and fixing design problems. 

This paper presents a detailed, well-founded critique of one of the
most powerful, but frustrating, tools in widespread use today. A
follow-up to earlier work published in 2013, it is distinguished from
most other discussion of software design by three things: 

  1. It clearly describes its design paradigm, which comprises
_concepts_ (the major elements of the user's mental model of the
system), _purposes_ (which motivate the concepts), and _misfits_ (which
are instances where concepts do not satisfy purposes, or contradict one
another). 

  2. It lays out Git's concepts and purposes, analyzes its main
features in terms of them, and uses that analysis to identify
mis-matches. 

  3. Crucially, it then analyzes independent discussion of Git (on
Stack Overflow) to see if users are stumbling over the misfits
identified in step 2. 

That would count as a major contribution on its own, but the authors go
further. They have designed a tool called Gitless that directly
addresses the shortcomings they have identified, and the penultimate
section of this paper presents a usability study that compares it to
standard Git. Overall, subjects found Gitles more satisfying and less
frustrating than Git, even though there was no big difference in
efficiency, difficulty, or confusion. Quoting the paper, "This apparent
contradiction might be due to the fact that all of the participants had
used Git before but were encountering Gitless for the first time
without any substantive training. Some participants (2 regular, 1
expert) commented that indeed their problems with Gitless were mostly
due to their lack of practice using it." 

This paper is one of the best examples I have ever seen of how software
designs ought to be critiqued. It combines an explicit, coherent
conceptual base, detailed analysis of a specific system, design
grounded in that analysis, and an empirical check of that design.
Sadly, nothing shows the actual state of our profession more clearly
than the way this work has been greeted: 

> In some respects, this project has been a fool's errand. We picked a
> product that was popular and widely used so as not to be investing
> effort in analyzing a strawman design; we thought that its popularity
> would mean that a larger audience would be interested in our
> experiment. In sharing our research with colleagues, however, we have
> discovered a significant polarization. Experts, who are deeply
> familiar with the product, have learned its many intricacies,
> developed complex, customized workflows, and regularly exploit its
> most elaborate features, are often defensive and resistant to the
> suggestion that the design has flaws. In contrast, less intensive
> users, who have given up on understanding the product, and rely on
> only a handful of memorized commands, are so frustrated by their
> experience that an analysis like ours seems to them belaboring the
> obvious.
>8
(This text is Copyright © Never Work in Theory, under the CC license.)

Re: Plugin mechanism(s) for Git?

[Konstantin Khomoutov]

On Fri, 15 Jul 2016 16:18:28 + (UTC)
Ben Peart  wrote:

> > Thanks for this great summary of the problem, Christian!
> > 
> > I think a generic plugin mechanism would be great but how would we
> > do it?
> 
> I’m also very glad to see the discussion about coming up with a good
> pattern for how git can interact with external code.  I had also
> noticed all the in-flight topics as I was searching for a good
> pattern to adopt.
> 
> > 
> > We could dynamically load libraries but this would force us to
> > freeze the ABI as mentioned by Duy:
> > http://article.gmane.org/gmane.comp.version-control.git/298463
> > 
> 
> I wouldn’t be too quick to dismiss dynamically loaded libraries as
> there are some distinct advantages over the other patterns especially
> performance and simplicity.  I realize it requires us to version the
> ABI but there are established patterns to manage this.  It also isn’t
> that much different than us having to freeze or version the protocol
> for communicating with a remote-helper.

Using dynamically loaded libraries precludes or greatly complicates
creation of plugins written in languages different from C (or C++ FWIW).

So that could be okay for some type of plugins (let's call them "core")
but not really for third-party / inhouse implementations.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dependencies required for offline installation

[Konstantin Khomoutov]

On Tue, 5 Jul 2016 07:45:12 -0400
Kevin Paxton  wrote:

> I’m looking to install git on a separate network that is running
> Redhat 5.5. I need to know what is the list of packages that I need to
> download to be able to install git-all? I plan on using git-svn to
> migrate an existing svn repo over to git as well. Svn version we have
> installed is 1.9.3.
> 
> Does the tarball contain all dependencies already?

No, it does not.  It depends on a few of external libraries (and
software packages) -- check it out yourself at [1].

It should be noted though that this list is not fixed.
IIUC the only hard dependency is zlib and all the other stuff is
optional.  SSH transport is implemented by calling an OpenSSH (or
compatible) client program, so this is a soft dependency.

Note that in your case you will need to have Perl 5.8+ because it's
used by the git-svn implementation, and that will use the Perl bindings
for Subversion (which, in turn, depend on both Perl and libsvn).
You'll need to have that stuff available and installed as well.

> Should I go that route?
> Or should I try and find all the rpm's required?

It's hard to tell.

RH 5.5 appears to be really really old so it's unlikely you'll find
official RPMs for recent Git versions.  You might try to look them up
in unofficial 3rd-party repos maintained by those who need to support
outdated systems.

This might get further complicated by the fact you appear to have
non-standard Subversion package (too fresh for RH 5.5 IMO).

Failing that, I'd have a VM running RH 5.5 and tried to build a set of
RPMs against the software packages you have deployed on the target
system.  The RPM specs can be grabbed from any up-to-date Redhatoid
system and backported.

1. https://github.com/git/git/blob/master/INSTALL
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split directories into branches

[Konstantin Khomoutov]

On Mon, 4 Jul 2016 17:03:46 -0400
shawn wilson  wrote:

[...]
> > I don't possess the official stance on this topic but AFAIK
> > user-level questions are fine on this list.
> 
> In that case :)
> ... still having issues w/ filter-branch:
[...]

I used something along these lines:

  git filter-branch -f --tree-filter \
'test -e my/new/dir || mkdir -p my/new/dir
  find . -mindepth 1 -maxdepth 1 \
  -type d -path ./my -prune -o -print \
  | xargs -n 30 mv -t ./my/new/dir' master 

More background on how it works [1] if you want.

1. https://groups.google.com/d/msg/git-users/hxFmfUZpj_k/9IQAQq40BwAJ
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split directories into branches

[Konstantin Khomoutov]

On Mon, 4 Jul 2016 14:15:58 -0400
shawn wilson  wrote:

[...]
> > I know Git tracks content, not files (and directory) but still many
> > folks have "stable" directories for their files, assign certain
> > semantics to them etc.  I've needed such transfers myself, and this
> > topic has been raised more than once by folks over there on the
> > git-users mailing list.
[...]
> Thanks for pointing out the users list - didn't notice it and sorry
> for posting a user question on a dev list.

I don't possess the official stance on this topic but AFAIK user-level
questions are fine on this list.  The git-users mailing list was
created -- as I understand it -- because of three reasons: 1) it's
easier to post to; 2) you don't receive all the bug reports and patch
traffic irrelevant to mere mortals; 3) you have good chances to get
even RTFM questions answered (mostly by those who just had RTFM
recently), though I'd say stackoverflow is better at this one. ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split directories into branches

[Konstantin Khomoutov]

On Mon, 4 Jul 2016 12:45:39 -0400
shawn wilson  wrote:

> I've got a chef cookbook repo where everyone started developing
> cookbooks in a single dev branch (not project specific). Minus a few
> edge cases, it should be fairly simple to split this up into feature
> branches based on /cookbooks/.
> 
> I tried:
> $ git filter-branch --subdirectory-filter cookbooks/--
>  And
> $ git subtree split --prefix cookbooks/ -b 
> 
> Which both seem to do the same thing (haven't looked at the subtree
> bash - guessing it does exactly the filter-branch). The issue is that
> it removes the directory tree (so obviously merges wouldn't work). I'm
> thinking some type of filter-branch --index-filter with a cherry pick
> (or similar) should work...?

To achieve what you're after I used `git subtree split` followed by
`git filter-branch --tree-filter ...` which moved all the files under
the directory hierarchy `git subtree split` removes.

I'd love if `git subtree split` had an option to preserve the prefix
(even better would be to have another option to rewrite the prefix)
because that would greatly simplify another use case for `git subtree`:
moving "a directory" with its full history from one repository into
another.  Presently, the user is able to split that directory out from
the source repository but when they subtree-merge it back in the new
repository, they are puzzled by the fact `git log` invoked on the new
history with the pathname prefix designating the "inserted" directory
does not traverse past the merge point which brought that directory in.

I know Git tracks content, not files (and directory) but still many
folks have "stable" directories for their files, assign certain
semantics to them etc.  I've needed such transfers myself, and this
topic has been raised more than once by folks over there on the
git-users mailing list.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with git-http-backend.exe as iis cgi

[Konstantin Khomoutov]

On Thu, 10 Mar 2016 07:28:50 +
Florian Manschwetus  wrote:

> I tried to setup git-http-backend with iis, as iis provides proper
> impersonation for cgi under windows, which leads to have the
> filesystem access performed with the logon user, therefore the
> webserver doesn't need generic access to the files. I stumbled across
> a problem, ending up with post requests hanging forever. After some
> investigation I managed to get it work by wrapping the http-backend
> into a bash script, giving a lot of control about the environmental
> things, I was unable to solve within IIS configuration. The
> workaround, I use currently, is to use "/bin/head -c
> ${CONTENT_LENGTH} | ./git-http-backend.exe", which directly shows the
> issue. Git http-backend should check if CONTENT_LENGTH is set to
> something reasonable (e.g. >0) and should in this case read only
> CONTENT_LENGTH bytes from stdin, instead of reading till EOF what I
> suspect it is doing currently.

The rfc [1] states in its section 4.2:

| A request-body is supplied with the request if the CONTENT_LENGTH is
| not NULL.  The server MUST make at least that many bytes available
| for the script to read.  The server MAY signal an end-of-file
| condition after CONTENT_LENGTH bytes have been read or it MAY supply
| extension data.  Therefore, the script MUST NOT attempt to read more
| than CONTENT_LENGTH bytes, even if more data is available.  However,
| it is not obliged to read any of the data.

So yes, if Git currently reads until EOF, it's an error.
The correct way would be:

1) Check to see if the CONTENT_LENGTH variable is available in the
   environment.  If no, read nothing.

2) Otherwise read as many bytes it specifies, and no more.

1. https://www.ietf.org/rfc/rfc3875
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with Integrated Vim Editor on Win 10

[Konstantin Khomoutov]

On Thu, 31 Mar 2016 10:20:28 -0700
Zachary Turner  wrote:

> I dug into this some more, and as surprising as it is, I believe the
> release of Git 2.8.0 is just busted.  I had an installer for 2.7.0
> lying around, so after uninstalling 2.8.0 and re-installing 2.7.0,
> everything works fine.
> 
> I'm not terribly active in the Git community so I don't know what the
> procedure is for things like this, but this seems like a fairly
> serious regression.  Suggestions on how to proceed?
[...]

The GfW maintainer had already spotted the bug (in the msys2-runtime,
IUUC) like some two hours ago -- see the bug #711 in the GfW tracker.

I'm pretty sure a fix will result in a corrected installer being
released.  If you can't wait for it for some reason and have to use
2.8.0, you could build GfW from the sources with the commit I mentioned
having been reverted before the build).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ssh key

[Konstantin Khomoutov]

On Sat, 28 May 2016 16:47:06 +0300
matveevma  wrote:

> Can i add SSH id_rsa.pub to GIT by shell terminal?

Hi!

First things first: this list has nothing to do neither with Github nor
with shells of any sort.  Please note that Github it not Git, it rather
is a hosting for Git projects, so if you have a Github-specific
question please direct it to Github support channels [2, 3], thanks.

As to the essence of your question, it appears that Github has a rich
RESTful API, so you should be able to register your SSH key using
`curl` or a similar tool using Github webAPI calls described in [1].

1. https://developer.github.com/v3/repos/keys/
2. https://help.github.com/
3. https://github.com/contact
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problems installing GIT on my MAC OS X 10.11.5

[Konstantin Khomoutov]

On Tue, 14 Jun 2016 17:49:50 +0100
Maria Jose Fernandez  wrote:

> I am very sorry but I am not understanding what you are saying. 
> I will try with homebrew and see if it works that way.

Torstean means:

1. Using the Finder, locate the Terminal application and run it.
   An open with command prompt (the "$" character) will appear.

2. Type there, literally:

 git --version

   and hit the Enter key.

   See whether it errors out at you -- something like

 bash: git: command not found

   or the version of the installed Git program will be printed,
   like in

 git version 2.9.0

   (yours might be different but that doesn't matter).

Whatever the outcome is, select that text and paste it into the message
you're composing to send here.

[...]
> > Do you think that you open a terminal and type
> > which git
> > git --version
> > and post the output here ?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problems installing GIT on my MAC OS X 10.11.5

[Konstantin Khomoutov]

On Tue, 14 Jun 2016 16:56:15 +0100
Maria Jose Fernandez  wrote:

> I am doing a data science course and need to download GIT but for
> some reason I can’t installed it. I called Apple but they couldn’t
> help and suggested me to contact you guys.

So you proceeded to http://git-scm.com/download/mac fetched the
installer, then found the downloaded file in the Finder, clicked it --
and then what happened?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to add custom metadata to Git commit object

[Konstantin Khomoutov]

On Mon, 30 May 2016 20:58:08 +0300
Kirill Likhodedov  wrote:

> Is it possible to add custom metadata to Git commit object? 
> Such metadata should be ignored by Git commands, but could be used by
> a 3-party tool which knows the format and knows where to look. 
> 
> I assume that this should be possible, given that Git objects are
> actually patches, and patches can contain additional details. But can
> this be done with the help of Git commands? 
[...]
> There are git-notes, which could be used for the purpose, but they
> are visible to the user via standard Git command, and could be used
> by the user for other purposes, so they are not very suitable for the
> task.

AFAIK, within your restrictions, it's not possible because there are
only two ways to add meta information for a Git commit:

* Store it externally and somehow correlate it with the commit.

  This is what git-notes does.

* Encode it directly into a commit object.

  Since you can't use your own headers in commit objects,
  you have to encode this information into the commit message in some
  form parsable by a machine.   This is what, say, git-svn does to
  make it possible to correlate the commits it creates with their source
  Subversion revisions.

In both cases the information can be viewed by the user.

What I can't really understand is what is so bad about the user being
able to peer at that data.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Local git repository url

[Konstantin Khomoutov]

On Thu, 19 Nov 2015 10:48:51 +
"Vambara, JayaPrakash (Infosys)" 
wrote:

> I am trying to setup a local git repository and manage it from local
> Jenkins set-up. So, both Jenkins and git are on my local desktop.
> 
> However, I am trying to give the Repository URL but with no luck.
> 
> My repository is in D drive in location D:\Git-Try
> 
> I tried to configure this Repository URL as --- file:///d/Git-Try
>  also file:///D:\Git-Try , but was not successful.
> 
> Can you please let me know what should be the Repository URL.
> 
> I have created the db in above location, pushed few files and
> commited them as well.

Try D:/Git-test first.

Otherwise it might heavily depend on how Jenkins interprets those URLs
and whether it even uses stock Git to access the repository (and not
something else like JGit).

To first rule out an issue with Jenkins you might just try cloning that
Git repo (local to local -- Git is fine with it).  Once you figure out
an URL which works for native Git (I assume you're talking about Git
for Windows), you can try to stick it to Jenkins and see it it works.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fw: [git-users] git fsck error - duplicate file entries - different then existing stackoverflow scenarios

[Konstantin Khomoutov]

A user recently asked an interesting question on the git-users list.
I think it warrants attentions of a specialists more hard-core than
we're there over at git-users.

So I'd like to solicit help if those knowledgeable, if possible.

Begin forwarded message:

Date: Wed, 11 Nov 2015 14:30:40 -0800 (PST)
From: Wind Over Water 
To: Git for human beings 
Subject: [git-users] git fsck error - duplicate file entries -
different then existing stackoverflow scenarios


Hi all,

I have a repo that is giving a 'git fsck --full' error that seems to be 
different from the existing questions and answers on stackoverflow on
this topic.  For example, in our fsck error it is not obvious which
file is actually duplicated and how/where.  And there is no commit sha
involved - apparently only blob and tree sha's.  But then finding good
documentation on this is challenging.

Might anyone have a pointer as to what to read to help figure out a 
solution/fix to the below?  Or know of a solution outright?

Thanks much in advance!

-sandy

$ git fsck --full

Checking object directories: 100% (256/256), done.

error in tree df79068051fa8702eae7e91635cca7eee1339002: contains
duplicate file entries

error in tree c2d09540a3c3f44c42be1dc8a2b0afa73a35f861: contains
duplicate file entries

Checking objects: 100% (623704/623704), done.

Checking connectivity: 623532, done.

dangling commit 4d1402c8c74c9f4de6172d7dbd5a14c41683c9e8


$ git ls-tree df79068051fa8702eae7e91635cca7eee1339002

100644 blob 14d6d1a6a2f4a7db4e410583c2893d24cb587766 build.gradle

12 blob cd70e37500a35663957cf60f011f81703be5d032 msrc

04 tree 658c892e15fbe0d3ea6b8490d9d54c5f2e658fc9 msrc

100644 blob f623819c94a08252298220871ac0ba1118372e59 pom.xml

100644 blob 9223cc2fddb138f691312c1ea2656b9dc17612d2 settings.gradle

04 tree c3bac1d92722bdee9588a27747b164baa275201f src


$ git ls-tree c2d09540a3c3f44c42be1dc8a2b0afa73a35f861

100644 blob 14d6d1a6a2f4a7db4e410583c2893d24cb587766 build.gradle

12 blob cd70e37500a35663957cf60f011f81703be5d032 msrc

04 tree 658c892e15fbe0d3ea6b8490d9d54c5f2e658fc9 msrc

100644 blob f623819c94a08252298220871ac0ba1118372e59 pom.xml

100644 blob 9223cc2fddb138f691312c1ea2656b9dc17612d2 settings.gradle

04 tree a5aa6758a25fee779cbb8c9717d744297071ea79 src


$ git show cd70e37500a35663957cf60f011f81703be5d032

src/main/java/com/foo/bar/baz/common/


$ git show 658c892e15fbe0d3ea6b8490d9d54c5f2e658fc9

tree 658c892e15fbe0d3ea6b8490d9d54c5f2e658fc9


BillingAggregator.java

BillingDataThriftAdapter.java

[...]

MetricsProcessor.java
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Automatic download at git-scm.com does not work (Was: [git-users] Cant download Git)

[Konstantin Khomoutov]

On Tue, 3 Nov 2015 04:55:22 -0800 (PST)
M Hendrickson  wrote:

> I am trying to download Git. When I click download for Mac OS X it
> says "download starting" but the download doesn't start.
> 
> There is a manual download option from sourceforge. But some have
> warned me that downloading from sourceforge often contains unwanted
> things included in the download.

That was a blunder of the (recent) past so I'd say it's OK to download
directly from SF.  Note that the Mac OS X build accessible from
git-scm.com, while being "officially blessed" is not prepared by the
upstream Git developers (as they only distribute the source code) but
rather this is a port coordinated there at that SF project you referred
to.

Well, I've just verified that what would be automacitally downloaded
has the same URL as that "download manually" link.
So you should be fine with the manual download.

> Does anyone know why the download from git-scm.com is not working?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Anonymous commit (empty Author and Committer)

[Konstantin Khomoutov]

On Fri, 30 Oct 2015 17:26:00 +0300
Andrei Borzenkov  wrote:

> See 
> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665ac
> 
> I was not even aware that this is possible. Is there anything on
> server side that can prevent it?

A hook running on "update" event could check the commits being pushed
and reject the update if some commit among those does not pass the
necessary checks.

Please see the githooks(5) manual page.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Why are submodules not automatically handled by default or at least configurable to do so?

[Konstantin Khomoutov]

On Tue, 27 Oct 2015 11:40:15 +
Nick  wrote:

> > Why not set alias(es) for that?
[...]
> But oh yes, there is another difficulty with aliases.  Eclipse users
> on Windows:
[...]

Not to counter your actual argument, but AFAIK EGit uses JGit which is
a Java implementation which does not call out to the "real" Git binary.
This basically means that if something gets implemented in the stock
Git, this won't affect JGit and EGit untill their respective
maintainers implement the same feature.

> they don't tend to love it if you tell them to install
> Cygwin, open a shell and type things into it.

On Windows, you typically want them to use Git for Windows, not
Cygwin.  Various GUI front-ends to Git working on Windows (such as Git
Extentions and TortoiseGit) rely on GfW to work as well.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug: gitk crashes for single file with German environment

[Konstantin Khomoutov]

On Fri, 23 Oct 2015 15:32:10 +0200
Jörg Bühmann  wrote:

> gitk crashes for single file with German environment
[...]

http://thread.gmane.org/gmane.comp.version-control.git/279910
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to rebase when some commit hashes are in some commit messages

[Konstantin Khomoutov]

On Tue, 13 Oct 2015 10:50:40 +0200
Francois-Xavier Le Bail  wrote:

> >> For example, if I rebase the following commits, I would want that
> >> if the commit hash 222... become 777...,
> >> the message
> >> "Update test output for "
> >> become
> >> "Update test output for 777..."
> >>
> >> Is it possible currently? And if yes how?
> > 
> > AFAIK, it's not possible other than by editing the message by hand.
> 
> It seems to me useful to be able to do it. Can we hope a new option?

How do you think this could be practically implemented?

A couple of things which immediately spring to my mind:

To begin with, you are free to specify just a few first characters of
the commit name you're referring to.  So the alogrythm which finds the
relevant commits them has to be smart to somehow avoid misfires.  Or
have knobs to tune it (like -M of `git log`).

OK, suppose that this is solved through the usage of some agreed-upon
keywords in the commit message.  Say, you adopt a policy to put
something like

  X-Refers-To: 2dd8a9d9bb33ebffccb2ff516497adc8535bcab4

in your commit message to make the finder tool happy.

Now think how exactly it should work.  First, any commit at all might
mention the name of the target commit in its commit message.  Okay,
let's suppose there will be some way to somehow prune the possible DAG
down.  Then what happens if the commit to change is a part of the chain
of commits reachable from some branch other than that you're rebasing?
Automatically rebasing it would rewrite that commits and all commits
"after" it -- possibly resulting in what the "Recovering from upstream
rebase" part of the git-rebase(1) manual page deals with.

Having said that, the feature you're after appears to me to be a
sensible thing to have but the possibility of its generic implementation
appears to be moot.

Note that to deal with narrow simple cases (all possibly affected
commits leave on the same branch you're rebasing, and come later than
the rebase's anchor) you could write a script which uses `git log` to
find those commits which need special care.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gitk cannot start in the latest version when using --all

[Konstantin Khomoutov]

On Tue, 29 Sep 2015 15:40:55 +0200
Christophe COEVOET  wrote:

> I'm installing git and gitk from the Ubuntu PPA maintained by the Git 
> team. I received the Git 2.6 update today.
> Since this update, I'm unable to launch gitk with --all. I'm
> receiving the following error message:
> 
> Error in startup script: bad menu entry index "Éditer la vue..."
>  while executing
> ".bar.view entryconf [mca "Edit view..."] -state normal"
>  invoked from within
> "if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne
> {}} {
>  # create a view for the files/dirs specified on the command line
>  se..."
>  (file "/usr/bin/gitk" line 12442)
> 
> Launching gitk without the --all option works fine.
> Launching gitk with the --branches option or the --tags option is
> also broken

Does it start if you run it via

$ LANG=C gitk --all

or

$ LANG=en_US.UTF-8 gitk --all

?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gitk cannot start in the latest version when using --all

[Konstantin Khomoutov]

On Tue, 29 Sep 2015 15:51:46 +0200
Christophe COEVOET  wrote:

> >> I'm installing git and gitk from the Ubuntu PPA maintained by the
> >> Git team. I received the Git 2.6 update today.
> >> Since this update, I'm unable to launch gitk with --all. I'm
> >> receiving the following error message:
> >>
> >> Error in startup script: bad menu entry index "Éditer la vue..."
> >>   while executing
> >> ".bar.view entryconf [mca "Edit view..."] -state normal"
> >>   invoked from within
> >> "if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd
> >> ne {}} {
> >>   # create a view for the files/dirs specified on the command
> >>   # line
> >>   se..."
> >>   (file "/usr/bin/gitk" line 12442)
[...]
> > Does it start if you run it via
> >
> > $ LANG=C gitk --all
> >
> > or
> >
> > $ LANG=en_US.UTF-8 gitk --all
> >
> > ?
> Yeah, both of these commands are working fine.

OK, so the problem is that some menu entry has the title "Edit view..."
which is for some reason not translated for your current locale,
and then some code tries to locate it using the original title
translated to French -- I fathom the command [mca] being called here
stands for "Message Catalog A-something" ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Specifying N revisions after the initial commit

[Konstantin Khomoutov]

On Tue, 22 Sep 2015 14:32:19 -0400
Josh Boyer  wrote:

> Please CC me as I'm not subscribed.
> 
> I was hoping someone could help me with the revision shorthand to get
> the commit sha of a commit N commits after the initial commit.

What happens if right after the initial commit, there have been five
branches created -- with no common commits except for the initial one?

That's the core limitation of the data model Git uses (and arguably any
other DVCS system): all commits form a directed acyclic graph.
The "directed" in that construct means that child commits contain a
link to their parent commit (or commits) but not vice-versa.

Hence, given any particular commit, you're able to trace all of its
ancestry, but the reverse is not possible.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: Translate Pro Git book to Russian and Ukrainian

[Konstantin Khomoutov]

On Sat, 12 Sep 2015 23:11:40 +0300
Dmitry Strelnikov  wrote:

> Good day!
> I am Russian and Ukrainian native speaker. I have a little free time
> and I want to help in translating.
> What I may do for it?

Please read [1] -- especially the section titled "Contributing" there.

1. https://github.com/progit/progit2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: Translate Pro Git book to Russian and Ukrainian

[Konstantin Khomoutov]

On Mon, 14 Sep 2015 12:48:52 +0300
Konstantin Khomoutov <kostix+...@007spb.ru> wrote:

> > Good day!
> > I am Russian and Ukrainian native speaker. I have a little free time
> > and I want to help in translating.
> > What I may do for it?
> 
> Please read [1] -- especially the section titled "Contributing" there.
> 
> 1. https://github.com/progit/progit2

Well, so basically [2] has a list of in-progress translations with the
links to their respective Git repos hosted on Github.  So I'd just get
in touch with their respective maintainers -- may be through opening an
issue of commenting on existing ones.

2. https://progit.org/translations
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug report Windows 10

[Konstantin Khomoutov]

On Mon, 10 Aug 2015 14:26:44 +0200
MS-Informatique i...@ms-informatique.be wrote:

 My Windows notebook got updated to Windows 10 and now my Git Bash
 doesn't start and when I open an existing repository from Git Gui, I
 am getting next error: 
 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error
 487 AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x41,
 State 0x1
 C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for
 cygwin's heap, Win32 error 0
 
 I am running GIT version 1.9.5 (latest build for Windows).

This version is essentially abandoned because the development
happens on packaging the 2.x series for Windows, and using the updated
runtime (MSYS2 instead of MSYS).

So please try this:

1) Fetch the latest version of the new Git for Windows available --
   currently its 2.4.6 RC5 [1].
   Supposedly you should try 64-bit version.

2) If the bug still does manifest itself, prease report it to the
   project's tracker [2].

1. https://github.com/git-for-windows/git/releases/tag/v2.4.6.windows.1
2. https://github.com/git-for-windows/git/issues/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git doesn't detect change, if file modification time is restored to original one

[Konstantin Khomoutov]

On Thu, 23 Jul 2015 11:14:11 +0200
Konrád Lőrinczi klorin...@gmail.com wrote:

[...]
 I accept these solutions as workarounds, but the real solution would
 be: Dev suggestions:
 1) Add a --force-reread option to git status, so user can force
 reread tree. git status --force-reread
 
 2) Add status.force-reread (true or false) option to .git/config so
 user can set this variable permanently for a repo.
 status.force-reread = false (should be default)
 
 Could be possible to implement 1) and 2) features to next git release?

Could you explain what's your real use case with preserving mtimes
while changing the files?  I mean, implementing mtime-stability
in your tools appears to be a good excersize in programming but what
real-world problem does it solve?

I'm asking because if you are not going to implement the changes to
Git you suggested yourself, then someone else should be *convinced* to
do so.  So far, your trouble appears to be too artifical to bother.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ssh admin git accidentally deleted

[Konstantin Khomoutov]

On Tue, 7 Jul 2015 20:30:59 +0700
agnes retnaningsih agnes.mon...@gmail.com wrote:

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

Git itself has no concept of users or user access controls.
From the description of the problem, it appears you're using
Gitolite [1] as a front-end to Git.

I can't unambiguously decode what delete ssh admin git means
because to me, it can mean at least two things:
1) You have deleted the SSH account used to push your Gitolite
   configuration on your server.
2) You have deleted the public key of the Gitolite admin user
   from your repository, and pushed.

In the case you have to log into your server (via SSH or other means)
first.

Then, in the first case,
1) Re-create the account;
2) Generate another SSH key for it;
3) Take the public part of this key, clone the Gitolite config
   repo locally (on the server), replace the admin's key there
   with the new key, commit, push.
4) Transport the private admin's key to the machine you're
   administering Gitolite from.

In the second case,
1) Clone the Gitolite config repo locally (on the server);
2) Revert the commit which nuked the admin's key (by using the
   regular `git revert` command, commit and push.

Note that this all implies you have enough permissions on your server.

1. https://github.com/sitaramc/gitolite
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] 4th release candidate of Git for Windows 2.x, was Re: 3rd release candidate of Git for Windows 2.x

[Konstantin Khomoutov]

On Mon, 29 Jun 2015 18:19:09 +0200
Johannes Schindelin johannes.schinde...@gmx.de wrote:

  I've finally took time to switch from my old msys1 release to this
  RC4, and immediately got hit by the fact Git is now speaking to me
  in Russian, which is not what I want (previously this behaviour was
  only exhibited by `git gui` and `gitk`).
  
  Should I make Git see LC_MESSAGES=en (or other thing like LANG) in
  the environment or is there some Git-local method to affect this
  behaviour? I tried to grep the release notes using relevant
  keywords but was left empty-handed.
 
 Personally, I would use LC_ALL=C. Maybe that's good for you, too?

After reading [1], I've ended up installing LANG=C into my user's
environment variables -- so far so good, thanks for the tip!

 I guess this would also make for a fine opportunity to add an option
 to the installer to switch the localization off?

I dunno.
While this definitely would be useful for some folks (mostly
old-school, like we do) but the problem with this setting is that it's
not specific to Git and can result in unpredictable behaviour in other
parts of the system.  Hence this option, if implemented, should somehow
be clearly marked as system-wide in the installer UI.

1. 
https://www.gnu.org/software/gettext/manual/html_node/Locale-Environment-Variables.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] 4th release candidate of Git for Windows 2.x, was Re: 3rd release candidate of Git for Windows 2.x

[Konstantin Khomoutov]

On Mon, 29 Jun 2015 16:37:54 +0200
Johannes Schindelin johannes.schinde...@gmx.de wrote:

  I just uploaded the 4th release candidate for the upcoming Git for
  Windows 2.x release. Please find the download link here:
 
  https://git-for-windows.github.io/#download
 
  The most important changes are the update to Git 2.4.5 and a fix
  for the crash when running Git Bash with a legacy `TERM` setting
  (this should help 3rd party software to upgrade to Git for Windows
  2.x).
  
  Thanks.
  It seems that this link:
  
 https://github.com/git-for-windows/git/releases/latest
  
  doesn't point to the latest release.
  
  Might be because the tags have the same date ?
 
 Wooops. Sorry for being so slow (been interviewing today). It should
 be correct now, can you verify, please?

Thanks for making all this real, Johannes!

I've finally took time to switch from my old msys1 release to this
RC4, and immediately got hit by the fact Git is now speaking to me in
Russian, which is not what I want (previously this behaviour was only
exhibited by `git gui` and `gitk`).

Should I make Git see LC_MESSAGES=en (or other thing like LANG) in the
environment or is there some Git-local method to affect this behaviour?
I tried to grep the release notes using relevant keywords but was left
empty-handed.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Repository Code Security (Plan Text)

[Konstantin Khomoutov]

On Wed, 24 Jun 2015 18:18:00 +
BGaudreault Brian bgaudrea...@edrnet.com wrote:

 If someone downloads code to their notebook PC and leaves the
 company, what protection do we have against them not being able to
 access the local code copy anymore?

What do you mean by local code?
That one which is on the notebook?
Then you can do literally nothing except for not allowing cloning your
Git repositories onto random computers in the first place.

If you instead mean the copy of code available in the repositories
hosted in your enterprise then all you need to do is to somehow
terminate the access of that employee who's left to those repositories.
(This assumes they're accessible from the outside; if they aren't, the
problem simply do not exist.)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Repository Code Scope (Plan Text)

[Konstantin Khomoutov]

On Wed, 24 Jun 2015 18:19:42 +
BGaudreault Brian bgaudrea...@edrnet.com wrote:

 What type of code scope should a repository contain?  Can it be one
 large program with many elements or should it just be part of a
 program or can it be a project with multiple programs?  What are the
 recommendations?

There are no recommendations because the structure of a
repositories depends on the use case.

If you're developing a library which might be used by more than a
single other project, host it in a separate repository, and in the
projects which use that library, refer to it using submodules.

If you have a project which contains internal submodules (say,
for .NET projects, it's common to have many so-called assemblies in a
single project to provide modularity), there's little point in messing
with separate repositories and it's simpler to keep everything in one
place.

Note that there are tools which allow you to split from a repository the
history touching only the contents of a particular directory, and then
glue such history back into some other repository.  Using these are not
exactly a walk in the park but at least this sort of things is doable.
This means you might start with a simple solution and then shape it
into a more appropriate form when you'll see the need for this.

I should also warn you that your question appear to be a bit too broad
which, IMO, suggests that you did not do much research on what's
offerred by Git and its ecosystem, what's in a Git repo, how is it
hosted, what are the best practices of managing complicated Git
projects etc.  And all this information is abundant in the internets...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: proxy_windows_386.exe Firewall Notification

[Konstantin Khomoutov]

On Thu, 11 Jun 2015 17:46:58 +
BGaudreault Brian bgaudrea...@edrnet.com wrote:

 Hello, when connecting to a Vagrant Shared VM via SSH, I'm getting a
 Windows Firewall prompt about 'proxy_windows_386.exe' (in C:\Program
 Files\hashicorp\vagrant\embedded\gems\gems\vagrant-share-1.1.0
 \localbin\), which looks like a malware-type name.  Here's the
 message: Windows Security Alert.  Windows Firewall has blocked some
 features of this app.  Windows Firewall has blocked some features of
 proxy_windows_386.exe on all public and private networks..
 
 So I did a quick search for this file name on the Internet as well as
 the Git-SCM.com/community site and haven't found any clear
 explinations about what this file is and if it's safe.  If this is a
 legitimate safe file, I think it's important that this is clearly
 documented in the Git documentation.  Can someone verify the details
 about this file?

I fail to get how did you manage to connect proxy_windows_386.exe
with Git.  Care to elaborate on this?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git lock files (Was: GIT for Microsoft Access projects)

[Konstantin Khomoutov]

On Tue, 9 Jun 2015 13:21:44 -0500
hack...@suddenlink.net wrote:

 Thanks folks, I am digesting all you have said.
 
 Now the command line I can do (I'm a programmer) but the secretary
 here I doubt.
 
 So is there at GUI interface for this? Does it work on Windows
 systems?

That's why I asked whether the thing you do really want is a document
management system, not a version control system.

Yes, Git works on Windows thanks to folks behind the Git for Windows
project (often and errorneously called msysGit in the internets)
and yes there do exist mature Windows GUI front-ends to it, with
TortoiseGit and Git Extensions being supposedly the most visible picks.

But there's such thing as an irreducible complexity: while these tools
strive to be user-friendly, and TortoiseGit even tries to make you
think you're using Subversion rather than Git, they won't hide all the
underlying complexity of a DVCS tool, which Git is, from the user.

So... I bet for your random user, it would be much easier to switch to
the browser window and upload another version of their document there,
with a short note describing what they do and why.  This is how a
typical DMS works.  You won't get all that awesomness Git gives you to
fiddle with your source code files but in return you'll get a system
which requires next to zero training for any layman to use it.

Please rememeber about [1].  Many of the statements that post does are
outdated but its essense remains to be true when it comes to handing
off Git to users not possessing ninja-level computer skills.
I especially recommend to think through this particular passage:

| They often struggle to use version control at all; are you now going
| to teach them the difference between “pull” and “update”, between
| “commit” and “push”? Look me in the eyes and say that with a straight
| face.

I also wonder how do you intend to explain them why they can't push
because someone else had just did that, and what to do about this, and
why.  (And whose version should win, in the end, as the files you
intend to work with are not subject for merging in the usual sense of
this word -- when it comes to plain text files.)

1. http://blog.red-bean.com/sussman/?p=79
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GIT for Microsoft Access projects

[Konstantin Khomoutov]

On Mon, 8 Jun 2015 9:45:17 -0500
hack...@suddenlink.net wrote:

[...]
 My question is, will GIT work with MS access forms, queries, tables,
 modules, etc?
[...]

Git works with files.  So in principle it will work with *files*
containing your MS access stuff.

But Git will consider and treat those files as opaque blobs of data.
That is, you will get no fancy diffing like asking Git to graphically
(or otherwise) show you what exact changes have been made to a
particular form or query between versions X and Y of a given MS access
document -- all it will be able to show you is commit messages
describing those changes.

So... If you're fine with this setting, Git will work for you,
but if not, it won't.

One last note: are you really sure you want an SCM/VCS tool to manage
your files and not a document management system (DMS) instead?
I mean stuff like Alfresco (free software by the way) and the like.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stash Feature

[Konstantin Khomoutov]

On Wed, 3 Jun 2015 17:22:57 +0200
Fabrizio Mancin fabma...@gmail.com wrote:

 I've a little request for you.
 What about saving date-time on git stash save command and show it on
 git stash show stash@{xxx}?
 I think it is a useful poperty to save.
 
 What do you think about it?

This information is already there as a stash entry is internally
represented as a commit (with one or more parents), and being a commit,
it possess all the standard attributes of a commit, including the
creation timestamp.

To get normal view of this commit just run

  git show stash@{0}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git-Win: case insensitive names

[Konstantin Khomoutov]

On Mon, 1 Jun 2015 13:30:19 -0400
Vadim Kramer vkokie...@gmail.com wrote:

 Just had to deal with a nasty cross-UNIX/Windows problem.
 
 Two files in the repository were in the same direcory and had the same
 name differing only by the case of some of the letters.  While
 checking them out, git wantonly confused them (conflated them into
 one) and got confused about them.
 
 I know it's an outlandish situation.  Still, when git is in a
 case-insensitive file system, it should at least check for this.

What it does it do if you have core.ignorecase set to on?

(And you did tell nothing about your platform and your Git version.)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Redirect git subcommand to itself?

[Konstantin Khomoutov]

On Wed, 27 May 2015 17:28:34 -0700
Stefan Beller sbel...@google.com wrote:

 so I just run into this problem again (which happens to me maybe
 twice a week): I want to do a git operations, so I type git  into
 my shell,
[...]
 then I copy the whole operation git revert --abort in this case and
 paste it to the shell and let go.
 The result looks like
 $ git git revert --abort
 git: 'git' is not a git command. See 'git --help'.
[...]
 I wonder if we want to make a git subcommand, which behaves exactly
 the same as git itself?
 Then git git git status would just return the same as git status.

In your ~/.whateverrc, put this:

git() {
  while [ $# -gt 0 ]; do
test $1 != git  break;
shift;
  done;
  command git $@;
}

This assumes a POSIX-compatible shell but I think you've got the idea.
(command is a builtin which forces interpreting the following word as
the name of an external program.)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: Sneak peek of the upcoming Git for Windows 2.x

[Konstantin Khomoutov]

On Sun, 12 Apr 2015 19:51:29 +0200
Johannes Schindelin johannes.schinde...@gmx.de wrote:

[...]
  * it is talking german to me
  
  would it be sufficient to delete
  c:\Apps\gitwin\mingw64\share\locale\de\LC_MESSAGES\
  resp the whole locale directory to let it speak english?
 
 Probably. But the canonical solution is to set the `LC_ALL` or `LANG`
 environment variables accordingly.

JFTR, that won't probably fix `git gui` and `gitk` as they are started
directly, not via shell scripts, and hence are unaffected by whatever
tweaks are done in ~/.bashrc *unless* they're started from the
interactive Git bash shell and hence see that environment.

I would hence just stick LC_MESSAGES=en (or LC_ALL, or LANG) into the
environment variables (on the user's level) and solve this problem once
and for all future programs making use of Unix-y locale setup
conventions.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re:

[Konstantin Khomoutov]

On Wed, 08 Apr 2015 23:58:58 +0200
Thomas Braun thomas.br...@virtuell-zuhause.de wrote:

[...]
  I am trying to run the latest git 1.9.5 installer on windows. When I
  run strings on libneon-25.dll it shows this:
  
  ./libneon-25.dll:OpenSSL 1.0.1h 5 Jun 2014
  
  But when I load this dll in dependency walker, it picks up
  msys-openssl 1.0.1m and has no trace of openssl-1.0.1h. My questions
  to you:
  
  1. Is libneon-25.dll statically linked with openssl-1.0.1h?
  2. If not, where is the reference to 1.0.1h coming from?
 
 I would be suprised if we link openssl statically into libneon. I
 guess libneon just reports against which openssl version it was
 *built*.
 
  I am asked to rebuild git with libneon-25.dll linked against
  openssl-1.0.1m. But I am having a feeling that this is not needed,
  since libneon is already picking the latest openssl version. Can you
  please confirm?
 
 You can download the development enviroment for git for windows here
 [1]. After installation, checkout the msys branch and then you can try
 to recomplile libneon using /src/subversion/release.sh.
 
 [1]:
 https://github.com/msysgit/msysgit/releases/download/Git-1.9.5-preview20150319/msysGit-netinstall-1.9.5-preview20150319.exe
[...]

JFTR, the discussion about the same issue has been brought up on
git-users as well [2].

(People should really somehow use the basics of netiquette and mention
in their posts where they cross-post things.)

2. https://groups.google.com/d/topic/git-users/WXyWE5_JfNc/discussion
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: confusion with some `git reset` commands

[Konstantin Khomoutov]

On Wed, 17 Dec 2014 01:09:08 +0630
Arup Rakshit arupraks...@rocketmail.com wrote:

[...]
 But I am looking for any differences -
 
 a) git reset --soft and git reset --keep
 b) git reset --hard and git reset --merge

Please consider reading
http://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git add single file and git add list of files behave differentely for ignored files

[Konstantin Khomoutov]

On Thu, 4 Dec 2014 10:06:23 +0100
Guilherme guibuf...@gmail.com wrote:

 I reported this issue on the git-user mailing list and they
 redirected me here.
 
 The problem I have observed is that with a ignored path `git add
 single file` behaves differently then `git add list of files`.
[...]

To those who's interested the original thread on git-users is
https://groups.google.com/d/topic/git-users/322tole9am8/discussion
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git push --all --tags

[Konstantin Khomoutov]

On Sat, 15 Nov 2014 04:44:19 + (UTC)
Ryan Jacobs ryan.mjac...@gmail.com wrote:

 $ git push --all --tags
 error: --all and --tags are incompatible
 
 Why are these flags incompatible? Just wondering 'cause I think that
 it would be a good feature to be able to push all of your branches
 and all of your tags to the server in one quick and simple command.

  git push --mirror

should do this.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

fatal unresolved deltas error

[Konstantin Khomoutov]

Hi,

I'm posting on behalf of Anjib Mulepati (Cc'ed) whose mails have
troubles getting in here.  Originally posted to git-users [*] but the
problem appears to be too complicated for that list.

[*] https://groups.google.com/d/topic/git-users/fnU3JtRuwH8/discussion

Below is the original Anjib's message.

I am trying to do push but getting this error

$ git push
Counting objects: 83, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (17/17), 1.32 KiB | 0 bytes/s, done.
Total 17 (delta 12), reused 0 (delta 0)
remote: fatal: unresolved deltas left after unpacking
error: unpack failed: unpack-objects abnormal exit
To //myserver/git/apps/myApp.git
! [remote rejected] master - master (unpacker error)
error: failed to push some refs to '//myserver/git/apps/myApp.git'

1. When I do new clean of the repo in new directory (say \newRepoDir)
I am getting error

$ git clone //myserver/git/apps/myApp.git/
Cloning into 'MyApp'...
done.
fatal: unable to read tree 18295307f1270da3c09e3de91890652af4ff7ca8
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

2. When I do cat in  new directory I am getting fatal: ..bad file error

$ git cat-file -t 18295307f1270da3c09e3de91890652af4ff7ca8
fatal: git cat-file 18295307f1270da3c09e3de91890652af4ff7ca8: bad file

3. But if I do cat in my current working directory it can tell its tree

$ git cat-file -t 18295307f1270da3c09e3de91890652af4ff7ca8
tree

My git repo is in network share drive and its Windows 7 and I am
working on Windows 7 machine too.

As client tool I am using Git for Windows 1.9.2.msysgit.0.

At this point I am thinking I have to push this tree in repo but not
sure how to do it or really that a solution.

Let me know what I have to do and if any further information is needed.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git download --- Virus

[Konstantin Khomoutov]

On Thu, 16 Oct 2014 12:35:33 +0300 (EEST)
risto.makini...@pp.inet.fi risto.makini...@pp.inet.fi wrote:

 I downloaded and started to Install Git.
 
 There is a Virus on you setup.
 Program that appears to have trojan-like features or behavior.
 
 Git/bin/pdfinfo.exe
 
 trojan.generic.[variant], gen:trojan.[variant]
 
 Why???

Because your antivirus software applies its (seemingly imperfect)
heuristics and thinks there's a virus while there's none.

To state this in a more blunt way: no there's no any virus in the Git
for Windows installation package.

The other possibility is you obtaining the installation package from
a place other than http://git-scm.com or some malware active on your
computer is changing the packages you're downloading on the fly.  The
latter is highly unlikely though.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Smart HTTP

[Konstantin Khomoutov]

On Mon, 13 Oct 2014 17:29:05 +
John Norris j...@norricorp.f9.co.uk wrote:

 I guess this comment is aimed at Scott Chacon.
 I have read your blog post on Smart HTTP 
 (http://git-scm.com/blog/2010/03/04/smart-http.html) and wondered if 
 there is any documentation that compares in terms of thoroughness
 with your sections in the book on using SSH, which does explain the
 basics so that anyone can get it working.
 I have tried setting up authenticated pull and push with HTTP (not 
 HTTPS) and Apache never asks for authentication during a pull and 
 refuses a push with a 403 error.

Looks like a sort-of followup to this discussion [1].

(John, being a good netizen, you should have included the link to that
discussion yourself, to put your uh comment in context and may be
actually get some useful responses.)

1. https://groups.google.com/d/topic/git-users/zcXYY1Le_F4/discussion
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BUG I can't start git on Windows 7

[Konstantin Khomoutov]

On Mon, 8 Sep 2014 11:15:44 +0200
Petr Bena benap...@gmail.com wrote:

 I installed git on my system using official package from git-scm.com
 but I can't launch it, I am always getting this error:
 
 C:\Users\petr.benaC:\Program Files (x86)\Git\bin\sh.exe --login -i
   0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32
 error 487 AllocationBase 0x0, BaseAddress 0x6857, RegionSize
 0x4, State 0x1 C:\Program Files (x86)\Git\bin\sh.exe: ***
 Couldn't reserve space for cygwin's heap, Win32 error 0
 
 
 At some point this could be an issue with cygwin, but I am not sure.
 Did anyone had similar issue?

Does [1] help?

I wonder, why the error message mentions Cygwin though.
One reason might be is that MinGW is originally a fork of some very
early Cygwin release so may be some error message is lingering there,
unmodified.

1. http://stackoverflow.com/a/24406417/720999
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EXT :Re: GIT and large files

[Konstantin Khomoutov]

On Tue, 20 May 2014 18:18:08 +
Stewart, Louis (IS) louis.stew...@ngc.com wrote:

 From you response then there is a method to only obtain the Project,
 Directory and Files (which could hold 80 GBs of data) and not the
 rest of the Repository that contained the full overall Projects?

Please google the phrase Git shallow cloning.

I would also recommend to read up on git-annex [1].

You might also consider using Subversion as it seems you do not need
most benefits Git has over it and want certain benefits Subversion has
over Git:
* You don't need a distributed VCS (as you don't want each developer to
  have a full clone).
* You only need a single slice of the repository history at any given
  revision on a developer's machine, and this is *almost* what
  Subversion does: it will keep the so-called base (or pristine)
  versions of files comprising the revision you will check out, plus
  the checked out files theirselves.  So, twice the space of the files
  comprising a revision.
* Subversion allows you to check out only a single folder out of the
  entire revision.
* IIRC, subversion supports locks, when a developer might tell the
  server they're editing a file, and this will prevent other devs from
  locking the same file.  This might be used to serialize editions of
  huge and/or unmergeable files.  Git can't do that (without
  non-standard tools deployed on the side or a centralized meeting
  point repository).

My point is that while Git is fantastic for managing source code
projects and project of similar types with regard to their contents,
it seems your requirements are mainly not suitable for the use case
Git is best tailored for.  Your apparent lack of familiarity with Git
might as well bite you later should you pick it right now.  At least
please consider reading a book or some other introduction-level
material on Git to get the feeling of typical workflows used with it.


1. https://git-annex.branchable.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

[Konstantin Khomoutov]

On Thu, 3 Apr 2014 17:18:50 +0400
ma...@slonopotamus.org wrote:

 I'm proud to announce WinGit:
 an attempt to bring Git powers to 64-bit Windows.
[...]
 Relationship with msysgit
 =
 
 Unlike msysgit, WinGit is a pure-Windows binary build with MSVC.
 
 Like msysgit, WinGit also uses msys environment (sh/perl/etc) both
 during build-time and runtime.
 
 WinGit adds a few patches to Git itself on top of msysgit ones.
 Patches are required due to insufficient testing of MSVC builds
 (caused by total absence of any MSVC-built Git distributions).
 
 All WinGit patches are sent upstream, just didn't get to master yet.

What is the state of Unicode support in WinGit?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug report -- Illegal instruction on Mac 10.6.8 without XCode installed

[Konstantin Khomoutov]

On Tue, 18 Mar 2014 01:33:25 -0700
Ray Hengst rkhen...@gmail.com wrote:

 Hi,
 I am running a Mac 10.6.8 and tried to install git-1.9.0 off of the
 installer (git-1.9.0-intel-universal-snow-leopard.dmg). The
 installation worked fine and gave no error messages. But whenever I
 type in a git command (see below for some I tried), it gives me this
 error message:
 Illegal instruction
 
 I am completely new to git and mostly new of Unix, but here are some
 commands I tried:
 git
 git help
 git config
 git init
 git clean
 git config --global user.name John Doe
 git status
 
 However, typing man git displays typical man pages.

This has nothing to do with your problem: the `man` program is not part
of Git and presumably works; it just finds and reads the specified
manual page--which is just plain text--renders it and shows to you.
And your problem is with misbehaving Git binary.

 I do not have Xcode installed. (it's very hard to find a legacy copy);
 the make command also is not present, so I can't use any of the
 workarounds I saw listed.
 I uninstalled git-1.9.0 successfully using the provided script, then
 downloaded the same file again (and installed it) to make sure I
 didn't get a corrupt copy. I had the same problem, however.
 If I can provide any more information just let me know.
 Thanks for any help you can provide.

I once came across this thread [1] on SO which says this might be due
to the binaries compiled for a newer version of the OS than you have
installed.  In any case, [2] suggests the installer is prepared by the
guy behind [3], and that project's bug tracker has a bug for exactly
your problem already filed [4].  You might want to chime in there
with more details if you feel like it.

1. http://stackoverflow.com/q/14268887/720999
2. http://git-scm.com/download/mac
3. http://sourceforge.net/projects/git-osx-installer/
4. http://sourceforge.net/p/git-osx-installer/tickets/97/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html