date:20140506

Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

2014-05-06 Thread John Keeping

On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote:
 John Keeping j...@keeping.me.uk writes:
 
 Having said all that, there is one caveat.
 
  Since the remote helper interface is stable and the remote helpers do
  not use any of the Git internals, I consider the risks of including them
  in core Git to outweigh the benefits of wider distribution.
 
 You are correct to say that a remote helper has to talk with a
 foreign system and it would not help to dictate the update schedule
 of helpers to match the release cycle of Git itself.  At the same
 time, however, the interface the remote helpers use to talk to Git
 has not been as stable as you seem to think, I am afraid.  For
 example, a recent remote-hg/bzr series needed some enhancements to
 fast-import to achieve the feature parity with native transports by
 adding a missing feature or two on the Git side.

This doesn't qualify as an unstable interface for me.  In this case, the
remote helpers could not support a feature without Git supporting it
first, which is quite natural and the remote helper can then guard that
feature with a capability check.  I do not think it likely that the
remote helper interface will ever change in such a way that all remote
helpers must be updated, at least not without a long deprecation period.

The Mercurial API makes no such guarantee; it is considered a private
implementation detail and most releases seem to contain some changes
that require all consumers to be updated.

There is a different level of urgency between you cannot use this new
feature until you update Git and if you update Mercurial then the
remote helper will stop working, and that's why I think the remote
helpers may benefit from a separate release schedule.
--
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: [PATCH] t3910: show failure of core.precomposeunicode with decomposed filenames

2014-05-06 Thread Erik Faye-Lund

On Mon, May 5, 2014 at 11:46 PM, Jeff King p...@peff.net wrote:
 On Sun, May 04, 2014 at 08:13:15AM +0200, Torsten Bögershausen wrote:

1. Tell everyone that NFD in the git repo is wrong, and
   they should make a new commit to normalize all their
   in-repo files to be precomposed.
   This is probably not the right thing to do, because it
   still doesn't fix checkouts of old history. And it
   spreads the problem to people on byte-preserving
   filesystems (like ext4), because now they have to start
   precomposing their filenames as they are adde to git.
  (typo:  
 ^added)
 I'm not sure if I follow. People running ext4 (or Linux in general,
 or Windows, or Unix) do not suffer from file system
 feature of Mac OS, which accepts precomposed/decomposed Unicode
 but returns decompomsed.

 What I mean by spreads the problem is that git on Linux does not need
 to care about utf8 at all. It treats filenames as a byte sequence. But
 if we were to start enforcing filenames should be precomposed utf8,
 then people adding files on Linux would want to enforce that, too.

 People on Linux could ignore the issue as they do now, but they would
 then create problems for OS X users if they add decomposed filenames.
 IOW, if the OS X code assumes all repo filenames are precomposed, then
 other systems become a possible vector for violating that assumption.

FWIW, Git for Windows also doesn't deal with that filenames are just
a byte-sequence-notion. We have patches in place that require
filenames to *either* be valid UTF-8 or Windows-1252. Windows itself
treats filenames as Unicode characters, not arbitrary byte sequences.
--
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

Summary of the problems with git pull

2014-05-06 Thread Felipe Contreras

Hi,

There has been a lot of discussion about why `git pull` is broken for so
many many workflows: [1][2][3][4][5], even as far back as [6].

Many issues has been brought up, and many proposed solutions, probably
too many for most people properly digest them, so here I'll try to
synthesize them.

Mainly there are two core problems with `git pull`:

 1) Many times it does a merge when it's not when people want
 2) Many times it does a merge opposite of the desired direction

The issue comes in trying to solve these problems in a way that would
not affect anybody negatively.

The simplest way to fix these issues unobtrusively would be to add
configurations for the new behavior. However, this wouldn't solve the
problem because as it has been discussed the vast majority of people
doing these bad merges are not advanced users, so they wouldn't
activate these options.

What is needed is to change the default behavior, but in a way that is
not obtrusive, and with backwards compatibility configuration.

The most concrete proposal is my patch series that puts everything in
place to enable fast-forward merged by default only. However, that still
doesn't solve the problem of the ordering of parents. Normally these two
issues would be independent of each other, but after further analysis I
think they are not.

== Two different kinds of pulls ==

It has become clear that the `git pull` command is in fact used to do
two very different things:

 1) Update the current branch

Most people do `git pull` like they would do `svn update`; to update
their current branch.

 2) Merge a remote branch

There are many use-cases of this.

The agreement so far is that 1) is the one that is broken, that is; a)
by default only fast-forwards should be allowed, and b) when a merge
happens the parents should be reverted (merge 'master' to
'origin/master').

It would be possible to differentiate these kinds by saying a `git pull`
that doesn't specify the location can be assumed as 1), and a
`git pull remote branch` that does as 2). Another possibility is to
assume only the upstream branch corresponds to 1).

Unfortunately it's the feeling of many people that this solution is not
clean, because it's two very different behaviors for the same command.
Furthermore even deeper analysis of the use-cases demonstrates there
would be a need to have different configurations for the different modes
(e.g. pull.updateMode and pull.integrateMode).

== git update ==

Another proposed solution is to have a new command: `git update`. This
command would be similar to `git pull --ff-only` by default, but it
could be configured to do merges instead, and when doing so in reverse.

An interesting side-effect of this new command is that it opens the
possibility of thinking about `git update --rebase` vs.
`git pull --rebase`.

For example:

  a) git update --merge

 Merge HEAD into @{upstream}

  b) git update --rebase

 Rebase HEAD onto @{upstream}

  c) git pull --merge github john

 Merge github/john into HEAD

  d) git pull --rebase github john

 Rebase github/john onto HEAD

Notice how the relationships between them are nice and consistent. Also,
d) was not possible before.

This solves essentially all the issues people presented in their
use-cases, except the differentiation between merging topic and upstream
branches, for which we might want to add different options in
`git pull`, but that's independent from the issues I mentioned at the
beginning.

Nothing changes for the users of `git pull`, except that perhaps we
would want --rebase to work in reverse, since the current
`git pull --rebase` would already rebase HEAD onto @{upstream}.

Personally my next step would be to port the changes I did for
pull.mode = merge-ff-only into a new command `git update`, which would
probably be a copy-paste from `git pull` and see how that turns out. In
addition, when running `git pull` without arguments we might want to add
a temporary notice explaining that perhaps the user wanted to type
`git update` instead.

Cheers.

[1] http://article.gmane.org/gmane.comp.version-control.git/233554
[2] http://article.gmane.org/gmane.comp.version-control.git/234295
[3] http://article.gmane.org/gmane.comp.version-control.git/225146
[4] http://article.gmane.org/gmane.comp.version-control.git/247237
[5] http://article.gmane.org/gmane.comp.version-control.git/247939
[6] http://article.gmane.org/gmane.comp.version-control.git/130819

-- 
Felipe Contreras
--
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 gui error with relocated repository

2014-05-06 Thread Pat Thoyts

Chris Packham judge.pack...@gmail.com writes:

On Tue, Apr 29, 2014 at 2:56 PM, Chris Packham judge.pack...@gmail.com wrote:
 Hi Pat,

 I'm running git 2.0.0-rc0 (haven't got round to pulling down rc1 yet)
 which includes gitgui-0.19.0 and I'm getting a new error when I run
 'git gui' in a repository with a .git file (created by git submodule).

 I can send you a screencap of the error message off list if you want
 but the text is

 No working directory ../../../repo

 couldn't change working directory to ../../../repo: no such file or 
 directory

My tcl is a little rusty but I think the problem might be this snippet.

# v1.7.0 introduced --show-toplevel to return the canonical work-tree
if {[package vsatisfies $_git_version 1.7.0]} {
if { [is_Cygwin] } {
catch {set _gitworktree [exec cygpath --windows [git rev-parse
--show-toplevel]]}
} else {
set _gitworktree [git rev-parse --show-toplevel]
}
} else {
# try to set work tree from environment, core.worktree or use
# cdup to obtain a relative path to the top of the worktree. If
# run from the top, the ./ prefix ensures normalize expands pwd.
if {[catch { set _gitworktree $env(GIT_WORK_TREE) }]} {
set _gitworktree [get_config core.worktree]
if {$_gitworktree eq } {
set _gitworktree [file normalize ./[git rev-parse --show-cdup]]
}
}
}

The  vsatisfies call probably doesn't handle '2.0.0.rc0' and the
fallback behaviour probably needs to normalise core.worktree


The _git_version variable has already been trimmed to remove such
suffixes so the version comparison here will be ok. It looks more likely
to be something to do with the .git being a file with a link being
mishandled. How did you setup this test repository with its link to a
parent?


 Here's some other info that might help

   $ git --version
   git version 2.0.0.rc0

   $ cat .git
   gitdir: ../.git/modules/repo

   $ git rev-parse --git-dir
   /home/chris/src/super/.git/modules/repo

   $ git config core.worktree
   ../../../repo

 Thanks,
 Chris


-- 
Pat Thoytshttp://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD
--
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

read-tree bug

2014-05-06 Thread Klishevich, Yauheni

Hello!

I have some troubles with git command ³read-tree².

I have big project and I try to add shared library to subdirectory. So I
made the following in my project (on master)

git remote add g...@bitbucket.org:ijin1984/groundwork.git
git fetch groundwork
git checkout b gwbranch groundwork/master
git checkout master
git read-tree --prefix=mb/trunk/src/ru.uralsib.dbo.client.iphone/libs/ -u
gwbranch
git commit m ³add groundwork to libs²
After that I make small change in one file inside libs (for example in
mb/trunk/src/ru.uralsib.dbo.client.iphone/libs/groundwork/notes.txt² and
commit with 
git commit a m ³test commit²

Then I made: 
git checkout gwbranch
git merge --squash -s subtree --no-commit master

And after this instead of merging I find the whole main project in subdir
³groundwork/Groundwork/Base.lproj².

If I do the 5-th command with ‹prefix option value equal to for example
³libs² tether than something like ³subdir/subsubdir/Š/libs² - all works
fine.

I think that it is bag, because I experimented quite a lot with deferrent
values. I think that problem in directory name with dots, i.e.
ru.uralsib.dbo.client.iphone².

Could you please help me with this issue. If you need to add some more
info about this case I will provide.

Thanks in advance.


Best regards, 
Eugene Klishevich
iOS-developer
skype: eugene.klishevich




--
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: [PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass

2014-05-06 Thread James Denholm

On 6 May 2014 08:01, Jeff King p...@peff.net wrote:
 [fixed David's address in cc list]

Ah, right. Wasn't sure what was going on there.

 On Tue, May 06, 2014 at 07:54:30AM +1000, James Denholm wrote:

 Given that subtree subtree doesn't really generate a lot of discussion,
 would it be advisable to wrap this up (barring further discussion) and send
 it off to Junio rather than waiting for further community consensus?

 I do not know if lack of discussion is a good reason to consider
 something in good shape; oftentimes it is a sign that nobody is
 interested in the area. We usually rely on area maintainers to give an
 OK to the patches if they are not something that the maintainer himself
 has an interest in.

Yeah, I certainly only meant that in the context of this particular
patch, post-review.

 However, in this case, you did get review, and I think it is pretty easy
 to see the patches are good even if one does not care about the
 particular area. So I think they are fine to pass on and apply.

Sounds good, I'll send it on up now. Thanks again for the help.

 Note also that patches like this are a great place to get started, as
 they help build trust in a contributor, who can later help out with
 area maintenance.

Yeah, to be honest, beyond the immediate goal of getting subtree in more
distros, that is kinda the plan. A bit of a practical experience in
contributing to the project, learning the specific ropes and such
before proposing more substantial discussion and fixes/changes.

---
Regards,
James Denholm.
--
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

[PATCH v2 5/5] contrib/subtree/Makefile: clean rule cleanup

2014-05-06 Thread James Denholm

git:Documentation/Makefile and others establish RM ?= rm -f as a
convention for rm calls in clean rules, hence follow this convention
instead of simply forcing clean to use rm.

subproj and mainline no longer need to be removed in clean, as they are
no longer created in git:contrib/subtree by make test. Hence, remove
the rm call for those folders.

Other makefiles don't remove *~ files, remove the rm call to prevent
unexpected behaviour in the future. Similarly, clean doesn't remove the
installable file, so rectify this.

Reviewed-by: Jeff King p...@peff.net
Signed-off-by: James Denholm nod.h...@gmail.com
---
 contrib/subtree/Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index f3834b5..d888d45 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -12,7 +12,8 @@ man1dir ?= $(mandir)/man1
 -include ../../GIT-VERSION-FILE
 
 # this should be set to a 'standard' bsd-type install program
-INSTALL ?= install
+INSTALL  ?= install
+RM   ?= rm -f
 
 ASCIIDOC = asciidoc
 XMLTO= xmlto
@@ -60,7 +61,7 @@ test:
$(MAKE) -C t/ test
 
 clean:
-   rm -f *~ *.xml *.html *.1
-   rm -rf subproj mainline
+   $(RM) $(GIT_SUBTREE)
+   $(RM) *.xml *.html *.1
 
 .PHONY: FORCE
-- 
1.9.2

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

[PATCH v2 2/5] contrib/subtree/Makefile: Use GIT-VERSION-FILE

2014-05-06 Thread James Denholm

GVF is already being used in most/all other makefiles in the project,
and has been for _quite_ a while. Hence, drop file-unique gitver and
replace with GIT_VERSION.

Reviewed-by: Jeff King p...@peff.net
Signed-off-by: James Denholm nod.h...@gmail.com
---
 contrib/subtree/Makefile | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 87797ed..f63334b 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -6,7 +6,10 @@ mandir ?= $(prefix)/share/man
 libexecdir ?= $(prefix)/libexec/git-core
 man1dir ?= $(mandir)/man1
 
-gitver ?= $(word 3,$(shell git --version))
+../../GIT-VERSION-FILE: FORCE
+   $(MAKE) -C ../../ GIT-VERSION-FILE
+
+-include ../../GIT-VERSION-FILE
 
 # this should be set to a 'standard' bsd-type install program
 INSTALL ?= install
@@ -44,11 +47,11 @@ $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML)
 
 $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT)
asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) \
-   -agit_version=$(gitver) $^
+   -agit_version=$(GIT_VERSION) $^
 
 $(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT)
asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \
-   -agit_version=$(gitver) $^
+   -agit_version=$(GIT_VERSION) $^
 
 test:
$(MAKE) -C t/ test
@@ -56,3 +59,5 @@ test:
 clean:
rm -f *~ *.xml *.html *.1
rm -rf subproj mainline
+
+.PHONY: FORCE
-- 
1.9.2

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

[PATCH v2 3/5] contrib/subtree/Makefile: s/libexecdir/gitexecdir

2014-05-06 Thread James Denholm

$(libexecdir) isn't used anywhere else in the project, while
$(gitexecdir) is the standard in the other appropriate makefiles. Hence,
replace the former with the latter.

Reviewed-by: Jeff King p...@peff.net
Signed-off-by: James Denholm nod.h...@gmail.com
---
 contrib/subtree/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index f63334b..579bb51 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -3,7 +3,7 @@
 
 prefix ?= /usr/local
 mandir ?= $(prefix)/share/man
-libexecdir ?= $(prefix)/libexec/git-core
+gitexecdir ?= $(prefix)/libexec/git-core
 man1dir ?= $(mandir)/man1
 
 ../../GIT-VERSION-FILE: FORCE
@@ -33,8 +33,8 @@ $(GIT_SUBTREE): $(GIT_SUBTREE_SH)
 doc: $(GIT_SUBTREE_DOC) $(GIT_SUBTREE_HTML)
 
 install: $(GIT_SUBTREE)
-   $(INSTALL) -d -m 755 $(DESTDIR)$(libexecdir)
-   $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(libexecdir)
+   $(INSTALL) -d -m 755 $(DESTDIR)$(gitexecdir)
+   $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(gitexecdir)
 
 install-doc: install-man
 
-- 
1.9.2

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

[PATCH v2 4/5] contrib/subtree/Makefile: Doc-gen rules cleanup

2014-05-06 Thread James Denholm

git:Documentation/Makefile establishes asciidoc/xmlto calls as being
handled through their appropriate variables, Hence, change to bring into
congruency with.

Similarly, MANPAGE_XSL exists in git:Documentation/Makefile, while
MANPAGE_NORMAL_XSL does not outside contrib/subtree. Hence, replace
MANPAGE_NORMAL_XSL with MANPAGE_XSL.

Reviewed-by: Jeff King p...@peff.net
Signed-off-by: James Denholm nod.h...@gmail.com
---
 contrib/subtree/Makefile | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 579bb51..f3834b5 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -14,8 +14,11 @@ man1dir ?= $(mandir)/man1
 # this should be set to a 'standard' bsd-type install program
 INSTALL ?= install
 
-ASCIIDOC_CONF  = ../../Documentation/asciidoc.conf
-MANPAGE_NORMAL_XSL =  ../../Documentation/manpage-normal.xsl
+ASCIIDOC = asciidoc
+XMLTO= xmlto
+
+ASCIIDOC_CONF = ../../Documentation/asciidoc.conf
+MANPAGE_XSL   = ../../Documentation/manpage-normal.xsl
 
 GIT_SUBTREE_SH := git-subtree.sh
 GIT_SUBTREE:= git-subtree
@@ -43,14 +46,14 @@ install-man: $(GIT_SUBTREE_DOC)
$(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir)
 
 $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML)
-   xmlto -m $(MANPAGE_NORMAL_XSL)  man $^
+   $(XMLTO) -m $(MANPAGE_XSL) man $^
 
 $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT)
-   asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) \
+   $(ASCIIDOC) -b docbook -d manpage -f $(ASCIIDOC_CONF) \
-agit_version=$(GIT_VERSION) $^
 
 $(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT)
-   asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \
+   $(ASCIIDOC) -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \
-agit_version=$(GIT_VERSION) $^
 
 test:
-- 
1.9.2

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

[PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass

2014-05-06 Thread James Denholm

contrib/subtree/Makefile is a shambles in regards to it's consistency
with other makefiles, which makes subtree overly painful to include in
build scripts.

The main issues are that calls are made to git itself in the build
process, and that a subtree-exclusive variable is used for specifying
the exec path. Patches 1/5 through 3/5 resolve these.

The cleanup fixes (4/5 and 5/5) are based on precedents set by other
makefiles across the project.

One problem is foreseen: 3/5 will necessitate that package maintainers
who already have git-subtree included in their packages update their
build-scripts.

Reviewed-by: Jeff King p...@peff.net
Signed-off-by: James Denholm nod.h...@gmail.com
Based-on-patch-by: Dan McGee dpmc...@gmail.com

James Denholm (5):
  contrib/subtree/Makefile: scrap unused $(gitdir)
  contrib/subtree/Makefile: Use GIT-VERSION-FILE
  contrib/subtree/Makefile: s/libexecdir/gitexecdir
  contrib/subtree/Makefile: Doc-gen rules cleanup
  contrib/subtree/Makefile: clean rule cleanup

 contrib/subtree/Makefile | 38 +++---
 1 file changed, 23 insertions(+), 15 deletions(-)

-- 
1.9.2

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

[PATCH v2 1/5] contrib/subtree/Makefile: scrap unused $(gitdir)

2014-05-06 Thread James Denholm

In 7ff8463dba0d74fc07a766bed457ae7afcc902b5, the references to gitdir
were removed but the assignment itself wasn't. Hence, drop the gitdir
assignment.

Reviewed-by: Jeff King p...@peff.net
Signed-off-by: James Denholm nod.h...@gmail.com
---
 contrib/subtree/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 4030a16..87797ed 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -4,7 +4,6 @@
 prefix ?= /usr/local
 mandir ?= $(prefix)/share/man
 libexecdir ?= $(prefix)/libexec/git-core
-gitdir ?= $(shell git --exec-path)
 man1dir ?= $(mandir)/man1
 
 gitver ?= $(word 3,$(shell git --version))
-- 
1.9.2

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

read-tree bug

2014-05-06 Thread Klishevich, Yauheni

Some more info:

If I use in 5-th command “—prefix=--prefix=mb/trunk/src/libs“ - issue is
reproduced

If “—prefix=--prefix=mb/libs“ - all work fine

With “—prefix=--prefix=mb/trunk/libs“ I haven’t tried, if it is desired
to check this case, just let me know.

On 5/6/14, 15:35, Klishevich, Yauheni yklishev...@scnsoft.com wrote:

Hello!

I have some troubles with git command ³read-tree².

I have big project and I try to add shared library to subdirectory. So I
made the following in my project (on master)

git remote add g...@bitbucket.org:ijin1984/groundwork.git
git fetch groundwork
git checkout b gwbranch groundwork/master
git checkout master
git read-tree --prefix=mb/trunk/src/ru.uralsib.dbo.client.iphone/libs/ -u
gwbranch
git commit m ³add groundwork to libs²
After that I make small change in one file inside libs (for example in
mb/trunk/src/ru.uralsib.dbo.client.iphone/libs/groundwork/notes.txt² and
commit with
git commit a m ³test commit²

Then I made:
git checkout gwbranch
git merge --squash -s subtree --no-commit master

And after this instead of merging I find the whole main project in subdir
³groundwork/Groundwork/Base.lproj².

If I do the 5-th command with ‹prefix option value equal to for example
³libs² tether than something like ³subdir/subsubdir/Š/libs² - all works
fine.

I think that it is bag, because I experimented quite a lot with deferrent
values. I think that problem in directory name with dots, i.e.
ru.uralsib.dbo.client.iphone².

Could you please help me with this issue. If you need to add some more
info about this case I will provide.

Thanks in advance.

Best regards,
Eugene Klishevich
iOS-developer
skype: eugene.klishevich

N�r��yb�X��ǧv�^�)޺{.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCH 7/9] bundle.c: convert leaf functions to struct object_id

2014-05-06 Thread Michael Haggerty

On 05/03/2014 10:12 PM, brian m. carlson wrote:
 Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
 ---
  bundle.c | 38 +++---
  1 file changed, 19 insertions(+), 19 deletions(-)
 
 diff --git a/bundle.c b/bundle.c
 index 1222952..798ba28 100644
 --- a/bundle.c
 +++ b/bundle.c
 @@ -11,11 +11,11 @@
  
  static const char bundle_signature[] = # v2 git bundle\n;
  
 -static void add_to_ref_list(const unsigned char *sha1, const char *name,
 +static void add_to_ref_list(const struct object_id *sha1, const char *name,
   struct ref_list *list)
  {
   ALLOC_GROW(list-list, list-nr + 1, list-alloc);
 - hashcpy(list-list[list-nr].sha1, sha1);
 + hashcpy(list-list[list-nr].sha1, sha1-oid);
   list-list[list-nr].name = xstrdup(name);
   list-nr++;
  }
 @@ -39,7 +39,7 @@ static int parse_bundle_header(int fd, struct bundle_header 
 *header,
   /* The bundle header ends with an empty line */
   while (!strbuf_getwholeline_fd(buf, fd, '\n') 
  buf.len  buf.buf[0] != '\n') {
 - unsigned char sha1[20];
 + struct object_id sha1;
   int is_prereq = 0;
  
   if (*buf.buf == '-') {
 @@ -53,9 +53,9 @@ static int parse_bundle_header(int fd, struct bundle_header 
 *header,
* Prerequisites have object name that is optionally
* followed by SP and subject line.
*/
 - if (get_sha1_hex(buf.buf, sha1) ||
 - (buf.len  40  !isspace(buf.buf[40])) ||
 - (!is_prereq  buf.len = 40)) {
 + if (get_sha1_hex(buf.buf, sha1.oid) ||
 + (buf.len  GIT_OID_HEXSZ  
 !isspace(buf.buf[GIT_OID_HEXSZ])) ||
 + (!is_prereq  buf.len = GIT_OID_HEXSZ)) {
   if (report_path)
   error(_(unrecognized header: %s%s (%d)),
 (is_prereq ? - : ), buf.buf, 
 (int)buf.len);
 @@ -63,9 +63,9 @@ static int parse_bundle_header(int fd, struct bundle_header 
 *header,
   break;
   } else {
   if (is_prereq)
 - add_to_ref_list(sha1, , 
 header-prerequisites);
 + add_to_ref_list(sha1, , 
 header-prerequisites);
   else
 - add_to_ref_list(sha1, buf.buf + 41, 
 header-references);
 + add_to_ref_list(sha1, buf.buf + 41, 
 header-references);

I think that 41 here is GIT_OID_HEXSZ + 1.

 [...]

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

Re: [PATCH 8/9] cache-tree: convert struct cache_tree to use object_id

2014-05-06 Thread Michael Haggerty

On 05/03/2014 10:12 PM, brian m. carlson wrote:
 Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
 ---
  builtin/commit.c   |  2 +-
  builtin/fsck.c |  4 ++--
  cache-tree.c   | 30 +++---
  cache-tree.h   |  3 ++-
  merge-recursive.c  |  2 +-
  reachable.c|  2 +-
  sequencer.c|  2 +-
  test-dump-cache-tree.c |  4 ++--
  8 files changed, 25 insertions(+), 24 deletions(-)
 
 diff --git a/builtin/commit.c b/builtin/commit.c
 index 9cfef6c..639f843 100644
 --- a/builtin/commit.c
 +++ b/builtin/commit.c
 @@ -1659,7 +1659,7 @@ int cmd_commit(int argc, const char **argv, const char 
 *prefix)
   append_merge_tag_headers(parents, tail);
   }
  
 - if (commit_tree_extended(sb, active_cache_tree-sha1, parents, sha1,
 + if (commit_tree_extended(sb, active_cache_tree-sha1.oid, parents, 
 sha1,
author_ident.buf, sign_commit, extra)) {
   rollback_index_files();
   die(_(failed to write commit object));
 diff --git a/builtin/fsck.c b/builtin/fsck.c
 index fc150c8..6854c81 100644
 --- a/builtin/fsck.c
 +++ b/builtin/fsck.c
 @@ -587,10 +587,10 @@ static int fsck_cache_tree(struct cache_tree *it)
   fprintf(stderr, Checking cache tree\n);
  
   if (0 = it-entry_count) {
 - struct object *obj = parse_object(it-sha1);
 + struct object *obj = parse_object(it-sha1.oid);
   if (!obj) {
   error(%s: invalid sha1 pointer in cache-tree,
 -   sha1_to_hex(it-sha1));
 +   sha1_to_hex(it-sha1.oid));
   return 1;
   }
   obj-used = 1;
 diff --git a/cache-tree.c b/cache-tree.c
 index 7fa524a..b7b2d06 100644
 --- a/cache-tree.c
 +++ b/cache-tree.c
 @@ -219,7 +219,7 @@ int cache_tree_fully_valid(struct cache_tree *it)
   int i;
   if (!it)
   return 0;
 - if (it-entry_count  0 || !has_sha1_file(it-sha1))
 + if (it-entry_count  0 || !has_sha1_file(it-sha1.oid))
   return 0;
   for (i = 0; i  it-subtree_nr; i++) {
   if (!cache_tree_fully_valid(it-down[i]-cache_tree))
 @@ -244,7 +244,7 @@ static int update_one(struct cache_tree *it,
  
   *skip_count = 0;
  
 - if (0 = it-entry_count  has_sha1_file(it-sha1))
 + if (0 = it-entry_count  has_sha1_file(it-sha1.oid))
   return it-entry_count;
  
   /*
 @@ -311,7 +311,7 @@ static int update_one(struct cache_tree *it,
   struct cache_tree_sub *sub;
   const char *path, *slash;
   int pathlen, entlen;
 - const unsigned char *sha1;
 + const struct object_id *sha1;
   unsigned mode;
  
   path = ce-name;
 @@ -327,21 +327,21 @@ static int update_one(struct cache_tree *it,
   die(cache-tree.c: '%.*s' in '%s' not found,
   entlen, path + baselen, path);
   i += sub-count;
 - sha1 = sub-cache_tree-sha1;
 + sha1 = sub-cache_tree-sha1;
   mode = S_IFDIR;
   if (sub-cache_tree-entry_count  0)
   to_invalidate = 1;
   }
   else {
 - sha1 = ce-sha1;
 + sha1 = (struct object_id *)ce-sha1;

This topic was discussed on the mailing list in the abstract.  Here is a
concrete example.

This cast is undefined, because you can't make the assumption that
cache_entry::sha1 has the same alignment and padding as (struct object_id).

I think the transition will be more tractable if you rewrite the data
structures *first*; in this case changing cache_entry::sha1 to be
(struct object_id) *before* rewriting code that works with it.

 [...]

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

Re: [PATCH 8/9] cache-tree: convert struct cache_tree to use object_id

2014-05-06 Thread Michael Haggerty

On 05/03/2014 10:12 PM, brian m. carlson wrote:
 [...]
 diff --git a/cache-tree.c b/cache-tree.c
 index 7fa524a..b7b2d06 100644
 --- a/cache-tree.c
 +++ b/cache-tree.c

In this file I also found a couple other 20 that could be converted to
GIT_OID_RAWSZ:

Around line 369:
strbuf_add(buffer, sha1, 20);

And around line 490 (three instances):
if (size  20)
goto free_return;
hashcpy(it-sha1, (const unsigned char*)buf);
buf += 20;
size -= 20;

I guess a search for \[24][0-9]\ will find most (but not all!) of
the literal constants that are derived from GIT_OID_RAWSZ and GIT_OID_HEXSZ.

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

Re: [PATCH 9/9] diff: convert struct combine_diff_path to object_id

2014-05-06 Thread Michael Haggerty

On 05/03/2014 10:12 PM, brian m. carlson wrote:
 Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
 ---
  combine-diff.c | 54 +++---
  diff-lib.c | 10 +-
  diff.h |  5 +++--
  3 files changed, 35 insertions(+), 34 deletions(-)
 
 diff --git a/combine-diff.c b/combine-diff.c
 index 24ca7e2..f97eb3a 100644
 --- a/combine-diff.c
 +++ b/combine-diff.c
 [...]

This file also has two literal 40 constants in it that are probably
GIT_OID_HEXSZ.

FWIW, I glanced over all of the patches in this series (though without
systematically looking for other literal constants that should be
derived from GIT_OID_RAWSZ and GIT_OID_HEXSZ) and, aside from the
problems that I already noted, they looked OK to me.

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

[PATCH 1/2] inline constant return from error() function

2014-05-06 Thread Jeff King

Commit e208f9c introduced a macro to turn error() calls
into:

  (error(), -1)

to make the constant return value more visible to the
calling code (and thus let the compiler make better
decisions about the code).

This works well for code like:

  return error(...);

but the -1 is superfluous in code that just calls error()
without caring about the return value. In older versions of
gcc, that was fine, but gcc 4.9 complains with -Wunused-value.

We can work around this by encapsulating the constant return
value in a static inline function, as gcc specifically
avoids complaining about unused function returns unless the
function has been specifically marked with the
warn_unused_result attribute.

We also use the same trick for config_error_nonbool and
opterror, which learned the same error technique in a469a10.

Reported-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
On Mon, May 05, 2014 at 05:29:38PM -0400, Jeff King wrote:

 I cannot think of any other way to make the compiler aware of the
 constant value, but perhaps somebody else is more clever than I am.

This came to me in a dream, and seems to work.

 cache.h   | 2 +-
 git-compat-util.h | 6 +-
 parse-options.h   | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/cache.h b/cache.h
index 107ac61..e2f12b0 100644
--- a/cache.h
+++ b/cache.h
@@ -1272,7 +1272,7 @@ extern int git_env_bool(const char *, int);
 extern int git_config_system(void);
 extern int config_error_nonbool(const char *);
 #if defined(__GNUC__)  ! defined(__clang__)
-#define config_error_nonbool(s) (config_error_nonbool(s), -1)
+#define config_error_nonbool(s) (config_error_nonbool(s), const_error())
 #endif
 extern const char *get_log_output_encoding(void);
 extern const char *get_commit_output_encoding(void);
diff --git a/git-compat-util.h b/git-compat-util.h
index f6d3a46..b4c437e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -331,7 +331,11 @@ extern void warning(const char *err, ...) 
__attribute__((format (printf, 1, 2)))
  * using the function as usual.
  */
 #if defined(__GNUC__)  ! defined(__clang__)
-#define error(...) (error(__VA_ARGS__), -1)
+static inline int const_error(void)
+{
+   return -1;
+}
+#define error(...) (error(__VA_ARGS__), const_error())
 #endif
 
 extern void set_die_routine(NORETURN_PTR void (*routine)(const char *err, 
va_list params));
diff --git a/parse-options.h b/parse-options.h
index 3189676..2f9be96 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -177,7 +177,7 @@ extern NORETURN void usage_msg_opt(const char *msg,
 extern int optbug(const struct option *opt, const char *reason);
 extern int opterror(const struct option *opt, const char *reason, int flags);
 #if defined(__GNUC__)  ! defined(__clang__)
-#define opterror(o,r,f) (opterror((o),(r),(f)), -1)
+#define opterror(o,r,f) (opterror((o),(r),(f)), const_error())
 #endif
 
 /*- incremental advanced APIs -*/
-- 
2.0.0.rc1.436.g03cb729

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

[PATCH 2/2] let clang use the constant-return error() macro

2014-05-06 Thread Jeff King

Commit e208f9c converted error() into a macro to make its
constant return value more apparent to calling code.  Commit
5ded807 prevents us using this macro with clang, since
clang's -Wunused-value is smart enough to realize that the
constant -1 is useless in some contexts.

However, since the last commit puts the constant behind an
inline function call, this is enough to prevent the
-Wunused-value warning on both modern gcc and clang. So we
can now re-enable the macro when compiling with clang.

Tested with clang 3.3, 3.4, and 3.5.

Signed-off-by: Jeff King p...@peff.net
---
I still get warnings when compiling with clang -O3, due to
-Warray-bounds. It looks like a bug, though. Clang complains that:

  strcmp(argv[1], git)

oversteps array bounds when the strcmp is expanded into a mess of
builtin magic. So I don't think we are doing anything wrong here.

 cache.h   | 2 +-
 git-compat-util.h | 2 +-
 parse-options.h   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/cache.h b/cache.h
index e2f12b0..35a3e6b 100644
--- a/cache.h
+++ b/cache.h
@@ -1271,7 +1271,7 @@ extern int check_repository_format_version(const char 
*var, const char *value, v
 extern int git_env_bool(const char *, int);
 extern int git_config_system(void);
 extern int config_error_nonbool(const char *);
-#if defined(__GNUC__)  ! defined(__clang__)
+#if defined(__GNUC__)
 #define config_error_nonbool(s) (config_error_nonbool(s), const_error())
 #endif
 extern const char *get_log_output_encoding(void);
diff --git a/git-compat-util.h b/git-compat-util.h
index b4c437e..70dc028 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -330,7 +330,7 @@ extern void warning(const char *err, ...) 
__attribute__((format (printf, 1, 2)))
  * trying to help gcc, anyway, it's OK; other compilers will fall back to
  * using the function as usual.
  */
-#if defined(__GNUC__)  ! defined(__clang__)
+#if defined(__GNUC__)
 static inline int const_error(void)
 {
return -1;
diff --git a/parse-options.h b/parse-options.h
index 2f9be96..7940bc7 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -176,7 +176,7 @@ extern NORETURN void usage_msg_opt(const char *msg,
 
 extern int optbug(const struct option *opt, const char *reason);
 extern int opterror(const struct option *opt, const char *reason, int flags);
-#if defined(__GNUC__)  ! defined(__clang__)
+#if defined(__GNUC__)
 #define opterror(o,r,f) (opterror((o),(r),(f)), const_error())
 #endif
 
-- 
2.0.0.rc1.436.g03cb729
--
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: [PATCH] add a reflog_exists and delete_reflog abstraction

2014-05-06 Thread Michael Haggerty

On 05/06/2014 12:57 AM, Ronnie Sahlberg wrote:
 This is a single patch that adds two new functions to try to hide the reflog
 implementation details from the callers in checkout.c and reflog.c.
 It adds new functions to test if a reflog exists and to delete it, thus
 allowing checkout.c to perform this if-test-then-delete operation without
 having to know the internal implementation of reflogs (i.e. that they are 
 files
 that live unde r.git/logs)
 
 It also changes checkout.c to use ref_exists when checking for whether a ref
 exists or not instead of checking if the loose ref file exists or not.
 Using ref_exists instead both hides the reflog implementation details from
 checkout.c as well as making the code more robust against future changes.
 It currently has a hard assumption that the loose ref file must exist at this
 stage or else it would end up deleting the reflog which is true today, as far
 as I can tell, but would break if git would change such that we could have
 a branch checked out without having a loose ref file for that branch.

For single patches, people usually don't send a separate cover letter.
Any comments that you want to make that are not suitable for the commit
message can go between the --- line and the diffstat of the patch email.

Regarding this change, I think before too long we will also need an API
to turn reflogs on for a reference.  We might want to add a flag to ref
transaction entries that cause the reflog to be created if it doesn't
already exist.  Reflogs can currently be created for a reference via the
config setting core.logAllRefUpdates or (for branches) by git branch
--create-reflog (maybe there are others).

Several tests in the test suite currently create reflog files by hand.
Thus we might also need a way to create reflogs at the command line by
the time we implement pluggable reference backends.

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

Re: [PATCH] refs.c: add new functions reflog_exists and delete_reflog

2014-05-06 Thread Michael Haggerty

On 05/06/2014 12:57 AM, Ronnie Sahlberg wrote:
 Add two new functions, reflog_exists and delete_reflog to hide the internal

Need comma after delete_reflog.

 reflog implementation (that they are files under .git/logs/...) from callers.
 Update checkout.c to use these functions in update_refs_for_switch instead of
 building pathnames and calling out to file access functions. Update reflog.c
 to use these too check if the reflog exists. Now there are still many places

s/too/to/

 in reflog.c where we are still leaking the reflog storage implementation but
 this at least reduces the number of such dependencies by one. Finally
 change two places in refs.c itself to use the new function to check if a ref
 exists or not isntead of build-path-and-stat(). Now, this is strictly not all

s/isntead/instead/

 that important since these are in parts of refs that are implementing the
 actual file storage backend but on the other hand it will not hurt either.

As an aside, I expect long term that reflog handling will be married
more tightly to reference handling and probably both will become
pluggable via a single mechanism.

 In config.c we also change to use the existing function ref_exists instead of

s/config.c/checkout.c/

 checking if the loose ref file exist. The previous code made the assumption
 that the branch we switched from must exist as a loose ref and thus checking
 the file would be sufficent. I think that assumption is always true in the

s/sufficent/sufficient/

 current code but it is still somewhat fragile since if git would change so 
 that
 the checkedout branch could exist as a packed ref without a corresponding

s/checkedout/checked-out/

 loose ref then this subtle 'does the lose ref not exist' check would suddenly
 fail.

I don't understand.  It can *already* be the case that the checked-out
branch only exists as a packed reference:

$ git checkout master
$ git pack-refs --all
$ find .git/refs -type f
$

So we already have a bug:

$ git config core.logallrefupdates true
$ git commit -m Initial --allow-empty
[master (root-commit) 3a03d51] Initial
$ git branch foo
$ git pack-refs --all
$ find .git/{refs,logs} -type f
.git/logs/HEAD
.git/logs/refs/heads/foo
.git/logs/refs/heads/master
$ git checkout foo
Switched to branch 'foo'
$ find .git/{refs,logs} -type f
.git/logs/HEAD
.git/logs/refs/heads/foo
$ history | tail -10

Note that the reflog for refs/heads/master is incorrectly deleted when
we run git checkout foo.

By the way, in case it wasn't clear to you I think the code in question
is trying to avoid leaving a reflog file behind when leaving an orphan
branch that hasn't actually been created yet.  So I think your change to
using ref_exists() will indeed fix the bug (but please test!)

Given that this is a real bug, I suggest breaking this change out into a
separate patch with a corresponding addition to the test suite.

 Signed-off-by: Ronnie Sahlberg sahlb...@google.com
 ---
  builtin/checkout.c |  8 ++--
  builtin/reflog.c   |  2 +-
  refs.c | 20 ++--
  refs.h |  6 ++
  4 files changed, 23 insertions(+), 13 deletions(-)
 
 diff --git a/builtin/checkout.c b/builtin/checkout.c
 index ff44921..f1dc56e 100644
 --- a/builtin/checkout.c
 +++ b/builtin/checkout.c
 @@ -651,12 +651,8 @@ static void update_refs_for_switch(const struct 
 checkout_opts *opts,
   }
   }
   if (old-path  old-name) {
 - char log_file[PATH_MAX], ref_file[PATH_MAX];
 -
 - git_snpath(log_file, sizeof(log_file), logs/%s, 
 old-path);
 - git_snpath(ref_file, sizeof(ref_file), %s, old-path);
 - if (!file_exists(ref_file)  file_exists(log_file))
 - remove_path(log_file);
 + if (!ref_exists(old-path)  reflog_exists(old-path))
 + delete_reflog(old-path);
   }
   }
   remove_branch_state();
 diff --git a/builtin/reflog.c b/builtin/reflog.c
 index c12a9784..0e7ea74 100644
 --- a/builtin/reflog.c
 +++ b/builtin/reflog.c
 @@ -369,7 +369,7 @@ static int expire_reflog(const char *ref, const unsigned 
 char *sha1, int unused,
   if (!lock)
   return error(cannot lock ref '%s', ref);
   log_file = git_pathdup(logs/%s, ref);
 - if (!file_exists(log_file))
 + if (!ref_exists(ref))

Shouldn't this be reflog_exists()?

   goto finish;
   if (!cmd-dry_run) {
   newlog_path = git_pathdup(logs/%s.lock, ref);
 diff --git a/refs.c b/refs.c
 index e59bc18..7d12ac7 100644
 --- a/refs.c
 +++ b/refs.c
 @@ -2013,7 +2013,6 @@ int dwim_log(const char *str, int len, unsigned char 
 *sha1, char **log)
  
   *log = NULL;
   for (p = ref_rev_parse_rules; *p; p++) {
 - struct stat st;
   unsigned char hash[20];
   char

86 matches

Mail list logo