Bug in update-index man page

[Kirill Likhodedov]

I've noticed the following text in the documentation pages for the 
`update-index` command:

   
   Files to act on. Note that files beginning with .  are discarded. 
This includes ./file and
   dir/./file. If you don't want this, then use cleaner names. The same 
applies to directories
   ending / and paths with //


It seems that the phrase "files beginning with .  are discarded." is incorrect, 
because update-index works correctly on files like `.gitignore`. It also seems 
that even names like `./file` are handled correctly after 
cfb0af1d50247e66ea1d46014650e60e9cfb87b9. Could you please verify and fix the 
doc if needed.

Thanks!
Kirill.

Re: Remove help advice text from git editors for interactive rebase and reword

[Kirill Likhodedov]

> On 24 Jul 2017, at 01:09 , Junio C Hamano  wrote:
> 
> Who is running "git commit --amend" and "git rebase -i" in the
> workflow of a user of your tool?  Is it the end user who types these
> commands to the shell command prompt, or does your tool formulate
> the command line and does an equivalent of system(3) to run it?
> 
> I am assuming that the answer is the latter in my response.

Yes, it is the latter case: the tool formulates the command line and forks a 
process.

> Not at all interested, as that would mean your tool will tell its
> users to set such a configuration variable and their interactive use
> of Git outside your tool will behave differently from other people
> who use vanilla Git, and they will complain to us.

That's not true, since the tool can (and would) use the `git -c 
config.var=value rebase -i` syntax to set the configuration variable just for 
this particular command, without affecting the environment.

Btw, if my proposal is so uninteresting, why the existing advice.* variables 
were previously introduced? I don't know the motivation, but assume that it was 
about making Git less wordy for experienced users. So I don't see any 
difference here.

> But stepping back a bit, as you said in the parentheses, your tool
> would need to grab these "hints" from Git, instead of having a
> separate hardcoded hints that will go stale while the underlying Git
> command improves, to be able to show them "separately".  

There is no need to call Git to get these "hints". They are quite obvious, 
well-known and can be hardcoded. However, I don't plan to use these hints 
anyway, since they are a bit foreign to the GUI of the tool I develop. For 
instance, for reword I'd like to show an editor containing just the plain 
commit message that the user is about to change. 


smime.p7s
Description: S/MIME cryptographic signature

Remove help advice text from git editors for interactive rebase and reword

[Kirill Likhodedov]

Hello,

is it possible to remove the helping text which appears at the bottom of the 
Git interactive rebase editor (the one with the list of instructions), and the 
one which appears at the bottom of the commit editor (which appears on 
rewording a commit or squashing commits)? 

The texts I'm talking about are:

# Rebase e025896..efc3d17 onto e025896¬
#¬
# Commands:¬
#  p, pick = use commit¬
...

and

# Please enter the commit message for your changes. Lines starting¬
# with '#' will be ignored, and an empty message aborts the commit.
# Not currently on any branch.¬
...


If there is no way to do it now, do you think it makes sense to provide a 
configuration variable for this, e.g. to introduce more advice.* config 
variables in addition to existing ones?

My motivation is the following: I'm improving the Git client inside of IntelliJ 
IDEA IDE and I would like to provide only the plain commit message text to the 
user (any hints can be shown separately, not inside the editor).

I know I can load the original commit message myself (but I prefer not to make 
extra calls when possible); and I can parse and strip out the help pages (but 
it is not very reliable since the text may change in future), so I'd appreciate 
any other solution to my problem, as well.

However I suppose that experienced command line users could also benefit from 
such configuration, since this helping text is intended only for newbies and is 
more like a noise for advanced users.

smime.p7s
Description: S/MIME cryptographic signature

Re: How to add custom metadata to Git commit object

[Kirill Likhodedov]

Thanks a lot for your suggestions!

> And "the user can use notes for other purposes" is not a good reason
> to reject them.  The whole point of allowing custom notes ref is so
> that Kirill is not restricted to use the usual notes/commits ref to
> store this custom notes in its dedicated notes/kirills-metadata ref.

I think the suggestion from Junio will suit best.
 
Somehow I missed the fact that notes can reside in several namespaces. 
Now I see that the notes are very powerful having namespaces
and several configuration and environment variables.

Jeff,

> there are user-invisible headers before the commit message, too, but we do not
> usually recommend people to add new headers here, as their semantics
> would be unclear to git. For example, when rebasing such a commit,
> should the header be preserved or not? It depends on its meaning.
> Whereas commit messages are always preserved.


Good point about rebase. 
Just out of curiosity, is it possible to add a custom invisible header 
to commit object with some Git command? 
git commit or commit-tree don’t have an option for this.


> On 30 May 2016, at 21:52 , Junio C Hamano <gits...@pobox.com> wrote:
> 
> Jeff King <p...@peff.net> writes:
> 
>> On Mon, May 30, 2016 at 08:58:08PM +0300, Kirill Likhodedov wrote:
>> ...
>>> 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.
>> 
>> Notes would work for this, too, but their main advantage is that they
>> can be created _after_ a commit has already been made (whereas anything
>> in the commit object itself will influence its sha1 id).
> 
> I would have said the same but with s/but/and/.  If the "rename
> hint" or whatever other "custom metadata" Kirill gives to a commit
> is found to be wrong, it can be corrected later.
> 
> And "the user can use notes for other purposes" is not a good reason
> to reject them.  The whole point of allowing custom notes ref is so
> that Kirill is not restricted to use the usual notes/commits ref to
> store this custom notes in its dedicated notes/kirills-metadata ref.

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

How to add custom metadata to Git commit object

[Kirill Likhodedov]

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? 



The reason why I am asking this - is to create a tool which could overcome 
false rename detection. 

As all of you know, if I make significant changes to the code together with 
rename, Git won’t detect this rename and will treat this change as added + 
deleted. And sometimes there are false rename detections as well. It would be 
useful to record the fact of rename and use it afterwards.

If a user is developing with our IDE (IntelliJ IDEA), we could remember the 
fact that he renamed a file, then write this information to the commit object, 
and when the commit information is requested (e.g. from the git log graphical 
view), the IDE could read the additional information of the commit and display 
the file as renamed, not as added + deleted. The IDE could also use this 
information to follow rename through the file history.

As a real example, in our project we are converting a lot of files from Java to 
Kotlin, and such conversion always looses history unless the developer 
remembers to prepare a separate rename-commit first, which is tedious. 

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.

Thanks a lot!
-- Kirill--
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

How to have EOL=LF and keep binary files auto-detection?

[Kirill Likhodedov]

Hi, 

I wonder if it is possible both to have LFs in all and only text files in 
working trees, and keep Git’s binary files auto-detection?

To be more precise:
* we want all text files to be checked out in LF; 
* we don’t want force people to set “core.autocrlf” to false, preferring to 
keep this configuration in .gitattributes; 
* we obviously don’t want binary files to be touched by eol-normalization; 
* we also don’t want to declare all possible patterns of binary files - Git is 
good enough in detecting them automatically.

However, I’ve found no way to do so.

If I declare `* eol=lf` in .gitattributes, it makes Git treat all files as text 
and thus convert CRLF to LF even in binary files. It is consistent with man, 
but a bit surprising to have e.g. a zip or png file modified in this way.

One could expect `* text=auto eol=lf` to work the way we want, but 
unfortunately it doesn’t work either: “eol=lf” forces “text” on all files.

Thanks a lot for your help!
-- Kirill.


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

git worktree fails to recreate existing branch even with -B

[Kirill Likhodedov]

Git doesn’t allow me to execute 
git worktree add -B   
where  already exists in the repository.

The command prints the following:
Preparing  (identifier )
fatal: Refusing to point HEAD outside of refs/

I’m trying to create a worktree on an existing branch , which should 
point to . This obviously should fail with “-b”, but I use “-B” 
and expect it to be reset to  as mentioned in the docs:

By default, -b refuses to create a new branch if it already exists.  
-B overrides this safeguard, resetting  to .

Do I miss something or there is a bug?

Steps to reproduce:

git init wt
cd wt
echo 'asd' > a.txt ; git add a.txt ; git commit -m initial
git branch br1
git worktree add -B br1 ~/temp/br1 master

Error message:
Preparing /Users/loki/temp/br1 (identifier br1)
fatal: Refusing to point HEAD outside of refs/

Thanks a lot!
-- Kirill--
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 show doesn't work on file names with square brackets

[Kirill Likhodedov]

Hi Johannes,

> On 06 Feb 2016, at 19:10 , Johannes Schindelin  
> wrote:
> 
>   git show 'HEAD:bra[ckets].txt' --
> 

Nice catch! It works for me even without quotes. Although this “--“ is 
mentioned in the error message, I didn’t even try since its meaning is totally 
unrelated with the problem ;) Anyway, thanks a lot for finding the workaround.--
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 show doesn't work on file names with square brackets

[Kirill Likhodedov]

Hi Duy,

> It's from 28fcc0b (pathspec: avoid the need of "--" when wildcard is
> used - 2015-05-02)

v2.5.0 is the first release which contains 28fcc0b.
I can confirm that older versions of Git work correctly without “--“:

# /opt/local/bin/git version
git version 1.7.1.1
# /opt/local/bin/git show HEAD:bra[ckets].txt 
asd

Looks like a regression?--
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

git show doesn't work on file names with square brackets

[Kirill Likhodedov]

I’ve faced a problem that `git show :` returns an error when 
 contains square brackets.

Interestingly, the problem is reproducible on "GNU bash, version 
3.2.57(1)-release (x86_64-apple-darwin15)", but not on "zsh 5.0.7 
(x86_64-pc-linux-gnu)”. The problem is also reproducible when called from a 
Java program by forking a process with given parameters.

Is it a bug or I just didn’t find the proper way to escape the brackets? 

Steps to reproduce:

git init brackets
cd brackets/
echo ‘asd’ > bra[ckets].txt
git add bra\[ckets\].txt
git commit -m initial
git show HEAD:bra[ckets].txt

Error:
fatal: ambiguous argument 'HEAD:bra[ckets].txt': both revision and filename
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]’

Neither escaping, not quoting doesn’t help:
git show HEAD:bra\[ckets\].txt
returns the same error

git show "HEAD:bra\[ckets\].txt”
returns empty output

Thanks a lot!
-- Kirill--
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 show doesn't work on file names with square brackets

[Kirill Likhodedov]

Hi Johannes,

thanks for your answer, but unfortunately it doesn’t help.

> On 06 Feb 2016, at 17:21 , Johannes Schindelin  
> wrote:
> 
> This is expected behavior of the Bash you are using. The commands that I
> think would reflect your intentions would be:
> 
>   git init brackets
>   cd brackets
>   echo 'asd' > 'bra[ckets].txt'
>   git add 'bra[ckets].txt'
>   git commit -m initial
>   git show 'HEAD:bra[ckets].txt’


Nope. This command sequence doesn’t work for me: the same error is returned:

# git show 'HEAD:bra[ckets].txt'
fatal: ambiguous argument 'HEAD:bra[ckets].txt': both revision and filename


> You could also escape the brackets with a backslash, as you did, but you
> would have to do it *every* time you write the path, not just in the `git
> add` incantation.


As I mentioned at the end of my original message, escaping doesn't help either. 
`git add` works fine both with and without escape. It was auto-completed by 
bash completion, and I just forgot to remove the backslashes before pasting the 
code here. At any case, escaping doesn’t work with `git show`.--
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

Default ordering of git log output

[Kirill Likhodedov]

Is it intended behavior that the default git log output (without ordering 
parameters) can show parents before children? 

The man says:
Commit Ordering
   By default, the commits are shown in reverse chronological order.
so it tells nothing about parent-to-child relationship.

I‘ve just faced an example in an open source repository, where I reproduced 
this behavior: a parent is shown before its child. (so if this behavior is not 
intended I can give the project URL for debugging)

So could you please clarify:
1. Is it true that the rule "no parents before all of its children are shown” 
is not guaranteed for default ordering?

2. What does "reverse chronological order” mean? How commits are actually 
sorted in git log? 

// I was always under impression that git log lists commit in the order in 
which they are “recorded" to the repository (e.g. pulled), since this seems to 
be both the fastest way, and also pretty acceptable from the ordering point of 
view.  

Thanks a lot!
-- Kirill.

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

git log date filter behavior with --date-order

[Kirill Likhodedov]

Hi,

I’ve faced a strange behavior when filtering git log by date.

When used with “--date-order” it gives significantly less results that when 
used without that option:

#  git log --pretty=oneline --remotes --after=Wed May 20 23:00:00 MSK 2015 
--before=Fri May 22 00:00:00 MSK 2015 -- | wc -l
  85
#  git log --pretty=oneline --remotes --after=Wed May 20 23:00:00 MSK 2015 
--before=Fri May 22 00:00:00 MSK 2015 --date-order -- | wc -l
  25

My assumption is that git log walks from the specified heads down to the past 
until it finds a commit which commit date matches the filter. Then it continues 
until it finds a commit which commit date doesn’t match the filter. Is it true?

Commits from “matching” and “unmatching” parts of the output are located in 
different branches which are being developed in parallel. 
AFAIU the flag “--date-order” is meant to place commits from different branches 
near each other, if they were performed at the same time.

But when I looked both at the “matching and the “unmatching” commits in the 
whole `git log --date-order` view, I’ve noticed that they are placed really far 
away from each other (with about 4K commits between them).

Could you please give me a hint, why can git log --date-order behave like that? 

I’ll be happy to provide more details if needed. 

Thanks a lot!
Kirill.--
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

Is it possible to list unpushed tags without accessing remote?

[Kirill Likhodedov]

Hi,

is it possible to know which tags are not yet pushed to a remote via a 
completely local command?

(e.g. the list of unpushed _commits_ may be received by ‘git log upstream..’)

I know it is possible to execute 'git ls-remote’ or 'git push --dry-run’, but 
both ask the remote server.
I’m almost sure that the answer is “NO”, but want to receive a confirmation 
from Git gurus :)


Thanks a lot!
-- Kirill.--
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: Is it possible to list unpushed tags without accessing remote?

[Kirill Likhodedov]

On 26 Jun 2014, at 23:04 , Junio C Hamano gits...@pobox.com wrote:

 Andreas Schwab sch...@linux-m68k.org writes:
 
 Not by default, but it is easy to configure your clone to fetch tags to
 a separate namespace.
 
 But then in order to learn what tags the remote has, you need to
 talk to the remote and it won't be complately a local operation
 anymore, no?

If I understand the solution correctly, it looks like it is not needed, if I’m 
OK with knowing which tags the remote had during the last fetch. 

Just like with commits: 'git log origin/master..’ can give me incorrect results 
if e.g. commits were rebased on the remote site. But we usually ignore such 
possibility as improbable.

--
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: Get all tips quickly

[Kirill Likhodedov]

Hi Michael, Ævar,

Thank you very much for your answers.

Each of 'git show-ref’ and ‘git for-each-ref’ is 2 times faster than ‘git log 
--branches --tags --remotes’ on “warmed up FS caches, but take the same time 
on “cold” FS.

It seems that all these approaches internally walk down from all references. 

So, given that there is no way to get just tips (I was actually hoping that Git 
might be storing them somewhere else), we will stick to ‘git show ref -d’.

Thanks a lot,
Kirill.


On 13 Apr 2014, at 22:29 , Ævar Arnfjörð Bjarmason ava...@gmail.com wrote:

 Tried git for-each-ref and the various options it has?
 
 Doing this for 35k tags is still going to be non-trivial.

On 13 Apr 2014, at 23:20 , Michael Haggerty mhag...@alum.mit.edu wrote:

 On 04/13/2014 04:19 PM, Kirill Likhodedov wrote:
 What is fastest possible way to get all “tips” (leafs of the Git log
 graph) in a Git repository with hashes of commits they point to?
 
 We at JetBrains are tuning performance of Git log integration in our
 IntelliJ IDEA and want to get all tips as fast as possible. Currently
 we use 'git log —branches --tags --remotes --no-walk’, but the
 problem is that it is slow if there are a lot of references. In our
 repository we have about 35K tags, and therefore the tags is the main
 slowdown. On the other hand, we have just a couple of dozens of tips
 as well as branch references, and `git log --branches --remotes` is
 very fast.
 
 So we are searching a way to get tags pointing to the graph leafs
 faster.
 
 The fastest ways to get all references plus the commits that are pointed
 at by annotated references would probably be `git show-ref -d`.  The
 funny-looking entries like refs/tags/v1.7.0^{} are the annotated tags
 peeled to the object that they ultimately refer.  But this command
 doesn't tell the types of the objects, and there can be trees and blobs
 mixed in.
 
 If your question is also to figure out the minimum set of references
 that are needed to include all tips (i.e., commits with no descendants),
 then the answer is trickier.  There is a command that should do what you
 say:
 
git merge-base --independent commit...
 
 but (1) with a lot of references, your arguments wouldn't all fit on the
 command line (recursive use of xargs might be needed), (2) I don't know
 if merge-base --independent is programmed to work efficiently on so
 many inputs, and (3) I don't know of a cheap way of getting a list of
 all commits referred to by references (i.e., dereferencing annotated
 tags but ignoring references/annotated tags that refer to trees or blobs).
 
 
 Another approach is to start by finding the leaf commits by SHA-1.  You
 can do this by listing all commits, and listing all commits' parents,
 and then finding the objects that appear in the first list but not the
 second.  This could look like
 
comm -23 \
(git log --all --pretty=format:'%H' | sort -u) \
(git log --all --pretty=format:'%P' | tr ' ' '\n' | sort -u)
 
 If you want reference names corresponding to these SHA-1s, you could use
 name-rev to convert the SHA-1s into refnames:
 
git rev-parse --symbolic-full-name $(
comm -23 \
(git log --all --pretty=format:'%H' | sort -u) \
(git log --all --pretty=format:'%P' | tr ' ' '\n' | sort -u) |
git name-rev --stdin --name-only
)
 
 The rev-parse --symbolic-full-name is needed because name-ref seems
 only able to emit abbreviated reference names.
 
 
 In practice, you might want to cache some of the results to avoid having
 to do a full tree traversal every time.
 
 We also tried to read tags by manually parsing .git files (it is
 faster than invoking git log), but unfortunately annotated tags in
 .git/refs/tags/ are written without the hashes they point to (unlike
 .git/packed-refs).
 
 I strongly recommend against parsing these files yourselves.  Your
 software would not be robust against any future changes to the file
 formats etc.
 
 Michael
 
 -- 
 Michael Haggerty
 mhag...@alum.mit.edu
 http://softwareswirl.blogspot.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

Get all tips quickly

[Kirill Likhodedov]

Hi, 

What is fastest possible way to get all “tips” (leafs of the Git log graph) in 
a Git repository with hashes of commits they point to?

We at JetBrains are tuning performance of Git log integration in our IntelliJ 
IDEA and want to get all tips as fast as possible. 
Currently we use 'git log —branches --tags --remotes --no-walk’, but the 
problem is that it is slow if there are a lot of references. In our repository 
we have about 35K tags, and therefore the tags is the main slowdown. On the 
other hand, we have just a couple of dozens of tips as well as branch 
references, and `git log --branches --remotes` is very fast.

So we are searching a way to get tags pointing to the graph leafs faster. 

We also tried to read tags by manually parsing .git files (it is faster than 
invoking git log), but unfortunately annotated tags in .git/refs/tags/ are 
written without the hashes they point to (unlike .git/packed-refs).

And that’s a pity that `git tag` doesn’t show the hashes.

Thanks a lot for any help!

-
Kirill Likhodedov
JetBrains
http://www.jetbrains.com
Develop with pleasure!

--
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 log --no-walk --tags produces strange result for certain user

[Kirill Likhodedov]

Hi everybody,

I received one more complaint for this issue, and now it appears in a public 
repository https://github.com/spray/spray 

To reproduce:

# git clone https://github.com/spray/spray 
# cd spray
# git log --no-walk --tags --pretty=%H %d --decorate=full | tail -3
3273edafcd9f9701d62e061c5257c0a09e2e1fb7  (tag: refs/tags/v0.8.0-RC1)
ff3a2946bc54da76ddb47e82c81419cc7ae3db6b  (tag: refs/tags/v0.7.0)
8b4043428b90b7f45b7241b3c2c032cf785479ce 

So here the last hash doesn't have a decoration.

Thanks for any help.
Kirill. 


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

git log --no-walk --tags produces strange result for certain user

[Kirill Likhodedov]

Hey,

I use the following commands to receive the list of tags together with hashes 
the point to:
  
git log --tags --no-walk --format=%H%d%x01 --decorate=full

Generally it works fine, however a user reported that for his repository this 
command returns the list containing several hashes without tag references. 
Something like this:

05c9a3a6247698ff740ca3a79828456347afdcef (HEAD, tag: refs/tags/2.33, 
refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/heads/master)

a7fda708d76d7f83d5a160b6b137b98b7677f771 (tag: refs/tags/2.44)
f119c2e7c69bb5ed1da5bae29c8754550ab96bde

07385a6ebe5a2e01e6ba9c8d0cb7b15c9a13f65d (tag: refs/tags/1.69)


Here third hash doesn't have a reference. There are 3 such hashes in his 
repository.

How can this happen? Is it a bug or some special scenario?

* I've already asked the user to execute `git tag --points-at` on these 
suspiciously tagged hashes: nothing was returned.
* `git show --decorate=full` executed on these hashes return commit details, 
and no references on them.
* From the log user sees that these hashes indicate some normal commits, 
nothing special at first glance.

Git version that he uses is 1.8.4.0.

Thanks!

-- Kirill.--
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? git show behaves incorrectly when called on a stash object

[Kirill Likhodedov]

On 20.03.2013, at 19:56, Matthieu Moy wrote:

 stash objects are commits with 2 parents (ie. merge commits). One commit
 is the HEAD you stashed from, and the other is the saved state of the
 index.
...
 Use git show --first-parent --name-status, it should do what you expect

Thanks a lot for clarifying that. It is actually mentioned in git help stash, 
but I've missed this.
With --first-parent I get the expected result. Thanks for your help.

 I'm not sure from the doc what the semantics of --name-status is
 for merge commits, but it seems it shows only files modified in both
 parents.

I think I've found the reason of this behavior.
git help show mentiones that:
 It also presents the merge commit in a special
 format as produced by git diff-tree --cc.
And git help diff-tree says that --cc implies -c, while -c lists only files 
which were modified from all parents.

-- Kirill.


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

Bug? git show behaves incorrectly when called on a stash object

[Kirill Likhodedov]

Hi,

I experience difference in behavior between `git stash show stash@{0}` and `git 
show stash@{0}`:

-

# git stash show --name-status stash@{0}
A   a
M   conflict.js
# git show --name-status stash@{0}
commit 05aa170746dc4e060f10710a92aed4592276f2d4
Merge: 737f544 7c2160f
Author: Kirill Likhodedov kirill.likhode...@gmail.com
Date:   Wed Mar 20 18:56:28 2013 +0400

   WIP on master: 737f544 master

MM  conflict.js

-

The first gives the correct result, while the second doesn't show the addition.
Is it a bug, or I'm just missing something?

Thanks a lot!
Kirill.--
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

Set core.ignorecase globally

[Kirill Likhodedov]

Hi,

Currently, core.ignorecase is set to true on case insensitive system like 
Windows or Mac on `git init` and `git clone`, and this setting is local to the 
created/cloned repository.
Here is the man entry:

core.ignorecase
   If true, this option enables various workarounds to enable git to 
work better on filesystems that are
   not case sensitive, like FAT. For example, if a directory listing 
finds makefile when git expects
   Makefile, git will assume it is really the same file, and continue 
to remember it as Makefile.

   The default is false, except git-clone(1) or git-init(1) will probe 
and set core.ignorecase true if
   appropriate when the repository is created.

I suggest to set this globally by default when Git is installed, because there 
is little sense to have this option false on case insensitive systems (it will 
lead to confusions when renaming a file by changing only the case of letters). 

--
Kirill Likhodedov
JetBrains, Inc
http://www.jetbrains.com
Develop with pleasure!

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