Re: [PATCH] pathspec: warn on empty strings as pathspec

2016-06-20 Thread Junio C Hamano 
Emily Xie  writes:

> For any command that takes a pathspec, passing an empty string will
> execute the command on all files in the current directory.

OK.

> This
> results in unexpected behavior.

Technically speaking, your expectation is what is wrong here.  An
empty string as a pathspec matches all paths.

> For example, git add "" adds all
> files to staging, while git rm -rf "" recursively removes all files
> from the working tree and index.

That is a logical consequence that an empty string is a pathspec
that matches everything.  If somebody wants to add everything in
their current directory, they can say 'git add ""'.  If you do not
want to do so, don't say 'git add ""'.

You need to argue why these are bad things to convince those who are
used to the current behaviour that it is OK to break them.

Here is my attempt.

An pathspec that is an empty string has been interpreted to
match any path, as pathspec match is a leading substring
match that honours directory boundary.  Just like pathspec
"dir/" (or "dir") matches "dir/file", "" matches "file".

However, a carelessly-written script may result in an empty
string assigned to a variable (perhaps caused by a bug in
it), and may end up passing an empty string to a Git command
invocation, i.e.

git rm "$path"
git add "$path"

which would affect all paths in the current directory.

We cannot simply reject an empty string given as a pathspec
to prevent this kind of mistake.  Because there surely are
existing scripts that take advantage of the fact that an
empty string matches all paths, such a change will break
scripts that legitimately have been using an empty string
for that purpose.

Instead, we need two step approach.  The first step is to
notice that the caller used an empty string as a pathspec,
give a warning to (1) declare that the use of an empty
string as "match all" will become invalid and (2) ask them
to use "." instead if they mean "match all".

After some release cycles, we can remove the warning and
turn an empty string used as a pathspec element as an error.

This patch is the first step.


> A two-step implemetation will
> prevent such cases.

There is some leap/gap in logic here.  

> This patch, as step one, invokes a warning whenever an empty
> string is detected as a pathspec, introducing users to the upcoming
> change. For step two, a follow-up patch several release cycles later
> will remove the warnings and actually implement the change by
> throwing an error instead.

This paragraph is OK, but I think I ended up covering the whole
thing in my attempt ;-).


> Signed-off-by: Emily Xie 
> Reported-by: David Turner 
> Mentored-by: Michail Denchev 
> Thanks-to: Sarah Sharp  and James Sharp 
> 
> ---
>  pathspec.c | 6 +-
>  t/t3600-rm.sh  | 6 +-
>  t/t3700-add.sh | 4 
>  3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/pathspec.c b/pathspec.c
> index c9e9b6c..79e370e 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -402,8 +402,12 @@ void parse_pathspec(struct pathspec *pathspec,
>   }
>  
>   n = 0;
> - while (argv[n])
> + while (argv[n]) {
> + if (*argv[n] == '\0')
> + warning(_("empty strings are not valid pathspecs and 
> will no longer "
> +   "be supported in upcoming releases"));
>   n++;

Three issues:

 * if argv[1] and argv[2] are both emtpy, the user will see the same
   message twice.  Is it intended?  Is it acceptable?

 * "Empty strings are not valid pathspecs" is just plain wrong.  It
   has been valid, but the warning message notifies that we are
   going to make it invalid what has been valid.

 * "Will no longer be supported" is just plain useless.  We are
   notifying that we will turn what they have been using as a valid
   feature invalid.  What needs to accompany that notification is
   how to update their script that have been happily working, which
   we are going to break with the future change, in a way that will
   keep working, i.e. "please use . instead if you meant to match
   all".


> +test_expect_success 'rm empty string should invoke warning' '
> + git rm -rf "" 2>&1 | grep "warning: empty string"
> +'

As your warning is in _("..."), you would need test_i18grep here, I think.

> +test_done
> \ No newline at end of file

Oops.
--
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；跨境电子商务物流供应商，天天有港車直派香港四號碼頭邦威安舍倉庫.

2016-06-20 Thread Paul Tsang 
Dear  Sir/Miss
本公司專業做中小微企業出口退税和单证報關出口物流运输，只要贵司拥有一般纳税人资质和能开17%的增值税专用发票，我司便能为贵司做退税；无论您有无进出口经营权，我司都可帮您做单证，
客户无需提供单证，只需提供货物清单，即可办理货物中国报关和香港清关；承运商品：玩具类，服装类，五金类，生活用品类，家具类等各种普通货物，敏感货物都可以承接。
以下報價為常見物流交貨報價，如有需要，歡迎來電詢價
1）散杂貨一般貿易退稅報關（单证報關）出口香港報價；
（一）中港散貨收费： RMB0.6/kg（最低收RMB200/單）
（二）報關费：RMB250
（三）检疫费及其杂费凭票据实报实销。（无商检则无此费用）
（四）商检换证凭条费用：RMB100  （无商检则无此费用）
注：以上費用不包含香港送客、入仓收費.
散貨香港派送收費標準:
A：九龍區： RMB180 ；B:新界區： RMB200  C: 香港區： RMB300
散貨香港入仓收費標準:
香港入仓费；RMB310（登记费、停车费等杂费实报实销）
注：1.以上香港派送或香港入仓首重500Kg，超出乘以RMB0.3/Kg.
所需资料：1. 一般贸易出口销售合同（需要盖公章和签字），加工贸易合同出口需要海关备案登记手册
2. 出口报关委托书（需有在指定盖章的两处盖公章）
3.出口销售发票（需有盖章的原件,一式两份） 4.出口装箱单（需有盖章的原件,一式两份）
操作时间： 周日到周五晚上12点前收货，报关资料一定要按规定随货一起交齐全.第二天下午到港，第三天派送/入仓完毕.
如有特殊情况，再作安排.

2）散貨速遞香港報價
一、广东江门/佛山/中山散（杂）货（買單）速递香港自提價；RMB0.9/KG或RMB200/CBM
广东清远/河源/惠州散（杂）货（買單）速递香港自提價；RMB0.9/KG或RMB200/CBM
广东汕头散（杂）货（買單）速递香港自提價；RMB1/KG或RMB200/CBM
浙江/江苏/上海/福建散（杂）货（買單）速递香港自提價；RMB1.5/KG或RMB250/CBM
二、香港派送首重500KG或首方3方，RMB200，续重RMB0.3/KG或续方RMB50/CBM（杂费实报实销）
三、香港入仓首重500KG或首方3方，RMB310，续重RMB0.3/KG或续方RMB50/CBM（登记费、停车费等杂费实报实销）
注；以上報價包報關費、清關費、派送費、入倉費.我司包所以报关单证文件

3）散貨速遞澳门報價
一、最低消费：RMB250/單
中澳自提价：RMB2.5/KG 或RMB250/CBM
二、澳门派送首重500KG或首方3方，RMB200，续重RMB0.3/KG或续方RMB50/CBM（杂费实报实销）
注；以上報價包報關費、清關費、派送費、入倉費.及所以报关单证文件

4）散（杂）貨交深圳盐田港倉、中外運，八达仓、金运达等外運倉報價；
一、最低消費；RMB800/單 （登记费等仓库杂费实报实销）
注；按公斤計算，包500KG，超出RMB0.5/KG;按方計算，包3CBM，超出RMB65/CBM(取大优先)

5）国内运输报价；
珠三角运输报价：RMB70/CBM或RMB0.4/KG+送货上门费用RMB200
深圳/东莞到福建报价:RMB120/CBM或RMB0.6/KG+送货上门费用RMB200
深圳/东莞到浙江报价:RMB160/CBM或RMB0.7/KG+送货上门费用RMB200
深圳/东莞到江苏报价:RMB170/CBM或RMB0.8/KG+送货上门费用RMB200
深圳/东莞到上海报价:RMB170/CBM或RMB0.8/KG+送货上门费用RMB200
深圳/东莞到京津翼报价:RMB180/CBM或RMB0.9/KG+送货上门费用RMB200

6）香港普貨，中檔貨到內地各省市報價；
快件包稅報關入口特點如下
A.手續簡單,海關監管條件簡單,不用單證不用批文,一些電子設備可以不需3C證明也可入口. 
B.速度快,次日到貨,适合緊急貨物通關.
C.如果貨量較大,可以采用每天分批報關方式. 
D.快件包稅報關不提供稅票,沒法進行稅票抵扣.
A 类
檔，白纸，纸袋，纸箱，纸盒，名片，日历，色卡，吊牌，说明书，目录，标贴，海报，胶纸，贴纸，胶条等
￥9/kg
B 类
塑料接头，铁芯，铁针，磁铁，弹簧，锡线，钢线，布料，纱线，线球，花边，饰扣，拉链，胶布，海绵等
￥11/kg
C 类
卤轮，滚轮，滑轮，电线，鼓纸，砂轮，石材，灯壳，灯罩，发饰品， PVC 皮，磨石，蕾丝，磨轮，漆包线等
￥13/kg
D 类
牛皮，羊皮，激光纸，皮光纸，烫金纸，轴心，色粉，颜料，胶水，文具，绒毛玩具，背包，尼龙袋等
￥15/kg
E 类
低价值运动用品，电筒，低价值灯饰，衣服，鞋样，模具，灯具，地毯，计算机接线，滤蕊，灯箱，润滑油等
￥16/kg
F 类
加热棒，低值变压器，电表，耳筒，耳机配件，气压配件，泵，空压表，活塞环，电热管，丝巾，领带等
￥21/kg
G 类
二极管，三极管，电容，电阻，电动起子，温度计 ，风扇，碳粉，干手机，耳咪线，投币器配件，游戏机控制杆等
￥36/kg
H 类
低值液晶显示片，温控器，烟雾感应器，音箱，定时器，低值缝纫机，助听器，探头，感应器，变频器，变速器等
￥41/kg
I 类
打印机，扫瞄仪，计算机机箱，显示器，路由器，集线器，接线盒，转换器，遥控器，传真机，钮扣电池，菲琳等
￥53-83/kg
注；單件貨值不要超過RMB5000.如果客戶謊報資料出現問題，由客戶自行承擔責任.

7）20尺/40尺45尺貨柜到香港報價；
廣東深圳-香港（20尺/40尺45尺）:RMB2600
廣東東莞-香港（20尺/40尺45尺）:RMB2900
廣東惠州-香港（20尺/40尺45尺）:RMB3500
廣東廣州-香港（20尺/40尺45尺）:RMB5700
杂费：
1.  租柜费：20尺40尺300港币/柜，含2天，超过按100港币/天计算。45尺350港币/柜，超过按150港币/天计算。
6.  超时费：无论大小柜装卸货统一按车到后计时，超3个小时，按100港币/小时计算。
7.  超重：20/40尺柜，货重不超18吨，超过按300-800港币加收超重费。
8.  压车费：以次日中午12点为限做完压车柜，12点前压夜60%，12点后压日80%，保底压夜1600港币，压日2000港币。
9.  返空费：车辆到达工厂后按完整运费收取，如果车未到工厂，按运费的80%收取。如果返空后货柜要交还码头
造成的吊柜费，存柜费实报，因返空柜需要办理文件，等办好文件后在去交柜办单费150，需支付本地拖车费600港币/柜。
11.  转关需加100港币—500港币 转关费，具体根据实际海关来定。
12.  同区加货300港币/点，跨区加货根据实际情况定。
13.  补料费：600港币含2天存仓费，超出每天加收存仓费100港币。
14.  进口需我司换文件，收文件费150港币/单，我司不代垫费用。

8）产地证文件；RMB200/单
一般原产地证CO
普惠制产地证FormA
东盟原产地证FormE
智利产地证FormF
中秘产地证FormR
中瑞产地证FormS
亚太产地证FormM
中巴原产地证FTA
中哥产地证FORML

9）散（杂）货速递（空運）台灣報價；
一、首重RMB30，續重RMB20
注；以上報價包報關費、清關費、派送費、入倉費.及所以报关单证文件
本公司還提供DHL国际件服务：经营经香港DHL中转到世界各地的快件，公司拥有DHL提供的操作系统，中转时效快，查询方便、安全可靠。

BEST REGARDS
曾生  
HAOCHING INT'L LOGISTICS LTD
M.P:86-13430873117
TEL: 852-31763891
WECHAT;13430873117
QQ；2540313891
SKYPE：HAOCHENGHK1987
E-MAIL: haochenghk1...@163.com

Re: Fast-forward able commit, otherwise fail

2016-06-20 Thread Junio C Hamano 
David Lightle  writes:

> I know that I have read that --ff-only and --no-ff are contradictory,
> but I believe that is somewhat ambiguously correct -- I believe the
> two flags contradict in the sense of "what to do with the merge
> commit", but not necessarily on the "when it can be done".

Traditionally we have mildly suggested against making otherwise
needless merge commit with "--no-ff".  We also have suggested
against keeping the history too linear, not because linear history
is bad, but because it will require rebasing soon before pushing out
your changes [*1*].

I personally would feel that what you seem to be aiming for is the
worst of both worlds in the sense that contributors are still forced
to rebase immediately before pushing out, which leads to
insufficiently tested version landing on truck, and at the same time
forcing the resulting history to have otherwise needless merges (the
latter is probably a much lessor of the two sins).

However, Git as a tool is not opinionated strongly enough to make it
hard to do these two things (independently).  I do not think it is
unreasonable to add a new mode of "merge" that rejects a resulting
history that is not shaped the way you like.  So far the command
rejected --ff-only and --no-ff given together, so if an updated Git
starts taking them together and creating a needless real merge and
failing only when the first parent does not fast-forward to the
second parent, nobody's existing workflow would be broken.

Having said that, you need to think things through.  Sample
questions you would want to be asking yourself are (not exhaustive):

 - What is your plan to _enforce_ your project participants to use
   this new mode of operation?

 - Do you _require_ your project participants to always pass a new
   option to "git merge" or "git pull"?

 - Do you force them to set some new configuration variables?  

 - Do you trust them once you tell them what to do?  

 - How will your project's trunk get their changes?

 - How you prevent some participants who misunderstood your
   instructions from pushing an incorrectly shaped history to your
   project?

If they are eventually pushing the result to a central repository
and that is how the project's overall history advances, then the
most reliable mechanism that is least limiting to your users is
pre-receive hook at that central repository that ensures the shape
of the history being pushed to update the branches.  You walk the
first-parent chain of the commits and ensure all the commits are
merges, and for each of these merges, its second parent is a
descendant of its first parent.  Otherwise you reject their push.

That way, your users can make normal merges while trying their
changes locally all they want without straightjacket.  Only when
they prepare the final history to be placed at the tip of the
project's official history, they need to make sure that the history
is shaped as you specified.


[Footnote]

*1* Your changes before rebasing may have seen enough
testing in one context (i.e. built on older base), but "rebase
immediately before push to ensure fast-forward" will force you to
publish a version that by definition will have little or no testing,
which may or may not work well with a different context.
--
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

Fast-forward able commit, otherwise fail

2016-06-20 Thread David Lightle 
Hello,

I am trying to build a git workflow in our enterprise and am almost
evenly torn between a "rebase workflow" and git-flow (which uses merge
instead of rebase, obviously).  We are using Bitbucket for pull
requests as code reviews (right or wrong).

I apologize if my inexperience with git shows through, but I'm wanting
to achieve the following --

Maintain two long-running branches (develop as a stable pre-release,
master as a deployed version), with short-term feature branches off of
develop and short-term release branches that are based on develop and
merge into master eventually (ie. a lightweight git-flow).

However, as part of this, I would prefer to require/ensure that each
feature branch is up-to-date and otherwise able to be fast-forwarded;
we currently have this with the bitbucket server setting requiring
--ff-only.

The other half of what I would prefer is to still perform the merge
commit, though, to ensure separate tracking of the feature branches
(ie. --no-ff).

I know that I have read that --ff-only and --no-ff are contradictory,
but I believe that is somewhat ambiguously correct -- I believe the
two flags contradict in the sense of "what to do with the merge
commit", but not necessarily on the "when it can be done".

I read an ancient post about on this list (which predates the
tri-state of fast-forward) that I believe could have allowed this to
work.

I have also read a few articles and posts that achieve this more as a
matter of practice than a workflow enforcement via git flags; for this
to be something to potentially get absorbed into a Bitbucket workflow,
I suspect it would need to a git flag (they now support merging via
--ff, --no-ff, --ff-only, --squash, and --squash-ff-only for their
hosted solution, for example).

Here are a few articles that say they prefer this approach (rebase and
then merge --no-ff):
https://walkingthestack.blogspot.com/2012/05/why-you-should-use-git-merge-no-ff-when.html
http://blog.differential.com/best-way-to-merge-a-github-pull-request/
http://victorlin.me/tags/rebase

Can anyone share their thoughts on workflows that might achieve what
I'm looking at here or opinions on adding the functionality I'm
describing?

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

[PATCH] pathspec: warn on empty strings as pathspec

2016-06-20 Thread Emily Xie 
For any command that takes a pathspec, passing an empty string will
execute the command on all files in the current directory. This
results in unexpected behavior. For example, git add "" adds all
files to staging, while git rm -rf "" recursively removes all files
from the working tree and index. A two-step implemetation will
prevent such cases.

This patch, as step one, invokes a warning whenever an empty
string is detected as a pathspec, introducing users to the upcoming
change. For step two, a follow-up patch several release cycles later
will remove the warnings and actually implement the change by
throwing an error instead.

Signed-off-by: Emily Xie 
Reported-by: David Turner 
Mentored-by: Michail Denchev 
Thanks-to: Sarah Sharp  and James Sharp 
---
 pathspec.c | 6 +-
 t/t3600-rm.sh  | 6 +-
 t/t3700-add.sh | 4 
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/pathspec.c b/pathspec.c
index c9e9b6c..79e370e 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -402,8 +402,12 @@ void parse_pathspec(struct pathspec *pathspec,
}
 
n = 0;
-   while (argv[n])
+   while (argv[n]) {
+   if (*argv[n] == '\0')
+   warning(_("empty strings are not valid pathspecs and 
will no longer "
+ "be supported in upcoming releases"));
n++;
+   }
 
pathspec->nr = n;
ALLOC_ARRAY(pathspec->items, n);
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index d046d98..4503a14 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -881,4 +881,8 @@ test_expect_success 'rm files with two different errors' '
test_i18ncmp expect actual
 '
 
-test_done
+test_expect_success 'rm empty string should invoke warning' '
+   git rm -rf "" 2>&1 | grep "warning: empty string"
+'
+
+test_done
\ No newline at end of file
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index f14a665..5dbe8c2 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -207,6 +207,10 @@ test_expect_success POSIXPERM,SANITY 'git add should fail 
atomically upon an unr
! ( git ls-files foo1 | grep foo1 )
 '
 
+test_expect_success 'git add empty string should invoke warning' '
+   git add "" 2>&1 | grep "warning: empty string"
+'
+
 rm -f foo2
 
 test_expect_success POSIXPERM,SANITY 'git add --ignore-errors' '
-- 
2.8.4

--
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 find commits unique to a branch

2016-06-20 Thread Nikolaus Rath 
On Jun 20 2016, Junio C Hamano  wrote:
> Nikolaus Rath  writes:
>
>> What's the best way to find all commits in a branch A that have not been
>> cherry-picked from (or to) another branch B?
>>
>> I think I could format-patch all commits in every branch into separate
>> files, hash the Author and Date of each files, and then compare the two
>> lists. But I'm hoping there's a way to instead have git do the
>> heavy-lifting?
>
> "git cherry" perhaps?

That seems to work only the "wrong way around". I have a tag
fuse_3_0_start, which is the common ancestor to "master" and
"fuse_2_9_bugfix". I'd like to find all the commits from fuse_3_0_start
to master that have not been cherry-picked into fuse_2_9_bugfix.

However:

* "git cherry fuse_3_0_start master release2.9" tells me nothing has
  been cherry-picked at all (only lines with +)

* "git cherry fuse_3_0_start release2.9 master" also tells me nothing
  has been cherry picked, but somehow shows a smaller total number of
  commits.

* "git cherry master release2.9 fuse_3_0_start" gives me the commits
  from fuse_2_9_bugfix that have not been cherry-picked into master
  (which seems to be in contradiction to the two earlier commands).


Am I missing something obvious?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
--
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

What's cooking in git.git (Jun 2016, #07; Mon, 20)

2016-06-20 Thread Junio C Hamano 
Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

The first batch for this cycle has been merged to 'master', the tip
of 'next' has been rewound and rebuilt, while a few topics are
temporarily ejected from 'next'.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[Graduated to "master"]

* ah/no-verify-signature-with-pull-rebase (2016-05-20) 1 commit
  (merged to 'next' on 2016-05-31 at 30add83)
 + pull: warn on --verify-signatures with --rebase

 "git pull --rebase --verify-signature" learned to warn the user
 that "--verify-signature" is a no-op when rebasing.


* aq/upload-pack-use-parse-options (2016-05-31) 1 commit
  (merged to 'next' on 2016-06-06 at 505f1ee)
 + upload-pack.c: use parse-options API

 "git upload-pack" command has been updated to use the parse-options
 API.


* et/pretty-format-c-auto (2016-05-27) 1 commit
  (merged to 'next' on 2016-05-31 at 1e9c920)
 + format_commit_message: honor `color=auto` for `%C(auto)`

 The commands in `git log` family take %C(auto) in a custom format
 string.  This unconditionally turned the color on, ignoring
 --no-color or with --color=auto when the output is not connected to
 a tty; this was corrected to make the format truly behave as
 "auto".


* ew/daemon-socket-keepalive (2016-05-25) 1 commit
  (merged to 'next' on 2016-05-31 at c32acf1)
 + daemon: enable SO_KEEPALIVE for all sockets

 When "git daemon" is run without --[init-]timeout specified, a
 connection from a client that silently goes offline can hang around
 for a long time, wasting resources.  The socket-level KEEPALIVE has
 been enabled to allow the OS to notice such failed connections.


* ew/fast-import-unpack-limit (2016-05-29) 2 commits
  (merged to 'next' on 2016-05-29 at af32aba)
 + fast-import: invalidate pack_id references after loosening
  (merged to 'next' on 2016-05-11 at ffd4efb)
 + fast-import: implement unpack limit

 "git fast-import" learned the same performance trick to avoid
 creating too small a packfile as "git fetch" and "git push" have,
 using *.unpackLimit configuration.


* jc/clear-pathspec (2016-06-02) 1 commit
  (merged to 'next' on 2016-06-06 at 9e7e291)
 + pathspec: rename free_pathspec() to clear_pathspec()

 We usually call a function that clears the contents a data
 structure X without freeing the structure itself clear_X(), and
 call a function that does clear_X() and also frees it free_X().
 free_pathspec() function has been renamed to clear_pathspec()
 to avoid confusion.


* jg/dash-is-last-branch-in-worktree-add (2016-05-31) 1 commit
  (merged to 'next' on 2016-06-02 at 3959ef6)
 + worktree: allow "-" short-hand for @{-1} in add command

 "git worktree add" learned that '-' can be used as a short-hand for
 "@{-1}", the previous branch.


* jk/rev-list-count-with-bitmap (2016-06-03) 2 commits
  (merged to 'next' on 2016-06-06 at dd9b30f)
 + rev-list: disable bitmaps when "-n" is used with listing objects
 + rev-list: "adjust" results of "--count --use-bitmap-index -n"

 "git rev-list --count" whose walk-length is limited with "-n"
 option did not work well with the counting optimized to look at the
 bitmap index.


* rs/xdiff-hunk-with-func-line (2016-06-09) 9 commits
  (merged to 'next' on 2016-06-10 at 9ff9ba8)
 + xdiff: fix merging of appended hunk with -W
  (merged to 'next' on 2016-06-02 at 0c2e335)
 + grep: -W: don't extend context to trailing empty lines
 + t7810: add test for grep -W and trailing empty context lines
 + xdiff: don't trim common tail with -W
 + xdiff: -W: don't include common trailing empty lines in context
 + xdiff: ignore empty lines before added functions with -W
 + xdiff: handle appended chunks better with -W
 + xdiff: factor out match_func_rec()
 + t4051: rewrite, add more tests

 "git show -W" (extend hunks to cover the entire function, delimited
 by lines that match the "funcname" pattern) used to show the entire
 file when a change added an entire function at the end of the file,
 which has been fixed.


* sb/submodule-misc-cleanups (2016-05-25) 1 commit
  (merged to 'next' on 2016-05-31 at 0d07b9c)
 + submodule update: make use of the existing fetch_in_submodule function

 Minor simplification.


* sb/submodule-recommend-shallowness (2016-05-27) 2 commits
  (merged to 'next' on 2016-05-31 at 1ee161c)
 + submodule update: learn `--[no-]recommend-shallow` option
 + submodule-config: keep shallow recommendation around
 (this branch is used by sb/submodule-clone-retry.)

 An upstream project can make a recommendation to shallowly clone
 some submodules in the .gitmodules file it ships.


* wd/userdiff-css (2016-06-03) 1 commit
  (merged to 'next' on

Re: [PATCH 1/2] archive-tar: write extended headers for file sizes >= 8GB

2016-06-20 Thread René Scharfe 

Am 16.06.2016 um 06:37 schrieb Jeff King:

The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.

These means that the largest size we can represent is
0777, or 1 byte short of 8GB. The correct solution
for a larger file, according to POSIX.1-2001, is to add an
extended pax header, similar to how we handle long
filenames. This patch does that, and writes zero for the
size field in the ustar header (the last bit is not
mentioned by POSIX, but it matches how GNU tar behaves with
--format=pax).

This should be a strict improvement over the current
behavior, which is to die in xsnprintf with a "BUG".
However, there's some interesting history here.

Prior to f2f0267 (archive-tar: use xsnprintf for trivial
formatting, 2015-09-24), we silently overflowed the "size"
field. The extra bytes ended up in the "mtime" field of the
header, which was then immediately written itself,
overwriting our extra bytes. What that means depends on how
many bytes we wrote.

If the size was 64GB or greater, then we actually overflowed
digits into the mtime field, meaning our value was was
effectively right-shifted by those lost octal digits. And
this patch is again a strict improvement over that.

But if the size was between 8GB and 64GB, then our 12-byte
field held all of the actual digits, and only our NUL
terminator overflowed. According to POSIX, there should be a
NUL or space at the end of the field. However, GNU tar seems
to be lenient here, and will correctly parse a size up 64GB
(minus one) from the field. So sizes in this range might
have just worked, depending on the implementation reading
the tarfile.

This patch is mostly still an improvement there, as the 8GB
limit is specifically mentioned in POSIX as the correct
limit. But it's possible that it could be a regression
(versus the pre-f2f0267 state) if all of the following are
true:

   1. You have a file between 8GB and 64GB.

   2. Your tar implementation _doesn't_ know about pax
  extended headers.

   3. Your tar implementation _does_ parse 12-byte sizes from
  the ustar header without a delimiter.

It's probably not worth worrying about such an obscure set
of conditions, but I'm documenting it here just in case.

There's no test included here. I did confirm that this works
(using GNU tar) with:

   $ dd if=/dev/zero seek=64G bs=1 count=1 of=huge
   $ git add huge
   $ git commit -q -m foo
   $ git archive HEAD | head -c 1 | tar tvf - 2>/dev/null
   -rw-rw-r-- root/root 68719476737 2016-06-15 21:07 huge

Pre-f2f0267, this would yield a bogus size of 8GB, and
post-f2f0267, git-archive simply dies.

Unfortunately, it's quite an expensive test to run. For one
thing, unless your filesystem supports files with holes, it
takes 64GB of disk space (you might think piping straight to
`hash-object --stdin` would be better, but it's not; that
tries to buffer all 64GB in RAM!). Furthermore, hashing and
compressing the object takes several minutes of CPU time.

We could ship just the resulting compressed object data as a
loose object, but even that takes 64MB. So sadly, this code
path remains untested in the test suite.


If we could set the limit to a lower value than 8GB for testing then we 
could at least check if the extended header is written, e.g. if 
ustar_size() could be convinced to return 0 every time using a hidden 
command line parameter or an environment variable or something better.




Signed-off-by: Jeff King 
---
  archive-tar.c | 28 +++-
  1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/archive-tar.c b/archive-tar.c
index cb99df2..7340b64 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -137,6 +137,20 @@ static void strbuf_append_ext_header(struct strbuf *sb, 
const char *keyword,
strbuf_addch(sb, '\n');
  }

+/*
+ * Like strbuf_append_ext_header, but for numeric values.
+ */
+static void strbuf_append_ext_header_uint(struct strbuf *sb,
+ const char *keyword,
+ uintmax_t value)
+{
+   char buf[40]; /* big enough for 2^128 in decimal, plus NUL */
+   int len;
+
+   len = xsnprintf(buf, sizeof(buf), "%"PRIuMAX, value);
+   strbuf_append_ext_header(sb, keyword, buf, len);
+}
+
  static unsigned int ustar_header_chksum(const struct ustar_header *header)
  {
const unsigned char *p = (const unsigned char *)header;
@@ -163,12 +177,21 @@ static size_t get_path_prefix(const char *path, size_t 
pathlen, size_t maxlen)
return i;
  }

+static inline unsigned long ustar_size(uintmax_t size)
+{
+   if (size < 0777UL)


Shouldn't that be less-or-equal?


+   return size;
+   else
+   return 0;
+}
+
  static void prepare_header(struct archiver_args *args,
   struct ustar_header *header,

Re: [PATCH 2/2] archive-tar: write extended headers for far-future mtime

2016-06-20 Thread René Scharfe 

Am 16.06.2016 um 06:37 schrieb Jeff King:

The ustar format represents timestamps as seconds since the
epoch, but only has room to store 11 octal digits.  To
express anything larger, we need to use an extended header.
This is exactly the same case we fixed for the size field in
the previous commit, and the solution here follows the same
pattern.

This is even mentioned as an issue in f2f0267 (archive-tar:
use xsnprintf for trivial formatting, 2015-09-24), but since
it only affected things far in the future, it wasn't worth
dealing with. But note that my calculations claiming
thousands of years were off there; because our xsnprintf
produces a NUL byte, we only have until the year 2242 to
fix this.

Given that this is just around the corner (geologically
speaking), and because the fix for "size" makes doing this
on top trivial, let's just make it work.

Note that we don't (and never did) handle negative
timestamps (i.e., before 1970). This would probably not be
too hard to support in the same way, but since git does not
support negative timestamps at all, I didn't bother here.

Unlike the last patch for "size", this one is easy to test
efficiently (the magic date is octal 010001):

   $ echo content >file
   $ git add file
   $ GIT_COMMITTER_DATE='@68719476737 +' \
 git commit -q -m 'tempori parendum'
   $ git archive HEAD | tar tvf -
   -rw-rw-r-- root/root 8 4147-08-20 03:32 file

With the current tip of master, this dies in xsnprintf (and
prior to f2f0267, it overflowed into the checksum field, and
the resulting tarfile claimed to be from the year 2242).

However, I decided not to include this in the test suite,
because I suspect it will create portability headaches,
including:

   1. The exact format of the system tar's "t" output.


Probably not worth it.


   2. System tars that cannot handle pax headers.


In t5000 there is a simple interpreter for path headers for systems 
whose tar doesn't handle them.  Adding one for mtime headers may be 
feasible.


It's just a bit complicated to link a pax header file to the file it 
applies to when it doesn't also contain a path header.  But we know that 
the mtime of all entries in tar files created by git archive are is the 
same, so we could simply read one header and then adjust the mtime of 
all files accordingly.



   3. System tars tha cannot handle dates that far in the
  future.

   4. If we replace "tar t" with "tar x", then filesystems
  that cannot handle dates that far in the future.


We can test that by supplying a test archive and set a prerequisite if 
tar (possibly with our header interpreter) and the filesystem can cope 
with that.



In other words, we do not really have a reliable tar reader
for these corner cases, so the best we could do is a
byte-for-byte comparison of the output.

Signed-off-by: Jeff King 
---
  archive-tar.c | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/archive-tar.c b/archive-tar.c
index 7340b64..749722f 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -185,6 +185,14 @@ static inline unsigned long ustar_size(uintmax_t size)
return 0;
  }

+static inline unsigned long ustar_mtime(time_t mtime)
+{
+   if (mtime < 0777)


That should be less-or-equal, right?


+   return mtime;
+   else
+   return 0;
+}
+
  static void prepare_header(struct archiver_args *args,
   struct ustar_header *header,
   unsigned int mode, unsigned long size)
@@ -192,7 +200,8 @@ static void prepare_header(struct archiver_args *args,
xsnprintf(header->mode, sizeof(header->mode), "%07o", mode & 0);
xsnprintf(header->size, sizeof(header->size), "%011lo",
  S_ISREG(mode) ? ustar_size(size) : 0);
-   xsnprintf(header->mtime, sizeof(header->mtime), "%011lo", (unsigned long) 
args->time);
+   xsnprintf(header->mtime, sizeof(header->mtime), "%011lo",
+ ustar_mtime(args->time));

xsnprintf(header->uid, sizeof(header->uid), "%07o", 0);
xsnprintf(header->gid, sizeof(header->gid), "%07o", 0);
@@ -292,6 +301,8 @@ static int write_tar_entry(struct archiver_args *args,

if (ustar_size(size) != size)
strbuf_append_ext_header_uint(_header, "size", size);
+   if (ustar_mtime(args->time) != args->time)
+   strbuf_append_ext_header_uint(_header, "mtime", args->time);

prepare_header(args, , mode, size);



--
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 0/3] fix local_tzoffset with far-in-future dates

2016-06-20 Thread Jeff King 
On Mon, Jun 20, 2016 at 03:11:23PM -0700, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > I still don't know how that screwed-up timestamp got _into_
> > a commit, so perhaps there is another bug lurking.  I couldn't convince
> > git to parse anything beyond 2100, and committing with
> > GIT_AUTHOR_DATE='@5758122296 +' works just fine.
> 
> Interesting.  The weirdest I could come up with was with
> 
> GIT_AUTHOR_DATE='@5758122296 -
> 
> which gets turned into the same timestamp but with -10039 timezone
> (simply because 99 minutes is an hour and 39 minutes).

Yeah, as weird as that is, I think it's reasonable. We _could_ turn
nonsense timezones into "+". That doesn't necessarily help the user
much, but at least it's less bizarre than making a 46-year timezone
offset.

I also looked for other uses of tm_to_time_t without checking for an
error return. Most of them do check. The exception is datestamp(), but
is calling it on the output of localtime(time()), which should generally
be sensible.

-Peff
--
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 find commits unique to a branch

2016-06-20 Thread Junio C Hamano 
Nikolaus Rath  writes:

> What's the best way to find all commits in a branch A that have not been
> cherry-picked from (or to) another branch B?
>
> I think I could format-patch all commits in every branch into separate
> files, hash the Author and Date of each files, and then compare the two
> lists. But I'm hoping there's a way to instead have git do the
> heavy-lifting?

"git cherry" perhaps?

--
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: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

2016-06-20 Thread Antoine Queru 

> 
> >> ...
> >> 
> > 
> > Hello Rémi, thanks you for your input ! I'll make the appropriate changes
> > and send a new version as soon as i can !
> 
> Hi Antoine,
> 
> do you have an updated version already or is this the one I should look at?
> http://article.gmane.org/gmane.comp.version-control.git/296445
> 
> Thanks,
> Lars

Hello Lars ! I'm actually in holidays, but I will try to send a new
version by the end of the week, it's nearly done. The code has been
refactored with what Matthieu and Remi told, so don't bother to read
the last version.

However, in the last version, if we want to deny an website,
including all schemes, we can blacklist the url without the
scheme. For example, "pushBlacklist = github.com". By doing so, this
remote is not an url anymore, and it can't be differenced with a local
relative path. It's a problem because these two have a different
treatement. The choice we made to solve this is to force the user to
put the scheme "file://" before any local relative path. What do you
think ?

Antoine
--
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 0/3] fix local_tzoffset with far-in-future dates

2016-06-20 Thread Junio C Hamano 
Jeff King  writes:

> I still don't know how that screwed-up timestamp got _into_
> a commit, so perhaps there is another bug lurking.  I couldn't convince
> git to parse anything beyond 2100, and committing with
> GIT_AUTHOR_DATE='@5758122296 +' works just fine.

Interesting.  The weirdest I could come up with was with

GIT_AUTHOR_DATE='@5758122296 -

which gets turned into the same timestamp but with -10039 timezone
(simply because 99 minutes is an hour and 39 minutes).

>   [1/3]: t0006: rename test-date's "show" to "relative"
>   [2/3]: t0006: test various date formats
>   [3/3]: local_tzoffset: detect errors from tm_to_time_t

Thanks, will queue.
--
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: may be bug in svn fetch no-follow-parent

2016-06-20 Thread Eric Wong 
+Cc: a bunch of folks who may know better how mergeinfo works in git-svn

Александр Овчинников  wrote:
> Why git svn fetch try to handle mergeinfo changes when
> no-follow-parent is enabled?

It probably should not...  --no-follow-parent isn't a common
config, though.  Can you try the patch below?

> Git try to follow parents regardless of this option value.
> If branch created without this option then git will follow
> parent succesfully
> If branch created with this option then git try to follow and
> fail with "cannot find common ancestor" error
> If branch does not exists (ignored) then git try to follow and
> fail with "couldn't find revmap" error. It is very long
> operation

Do you have an example repo you could share with us?

Thanks.

I still don't think I've encountered a repo which uses
mergeinfo myself.
Hopefully the following patch works for you:

-8<
Subject: [PATCH] git-svn: skip mergeinfo with --no-follow-parent

For repositories without parent following enabled, computing
mergeinfo can be expensive and pointless.

Note: Only tested on existing test cases.
---
 perl/Git/SVN.pm | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index d94d01c..bee1e7d 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1905,15 +1905,22 @@ sub make_log_entry {
 
my @parents = @$parents;
my $props = $ed->{dir_prop}{$self->path};
-   if ( $props->{"svk:merge"} ) {
-   $self->find_extra_svk_parents($props->{"svk:merge"}, \@parents);
-   }
-   if ( $props->{"svn:mergeinfo"} ) {
-   my $mi_changes = $self->mergeinfo_changes
-   ($parent_path, $parent_rev,
-$self->path, $rev,
-$props->{"svn:mergeinfo"});
-   $self->find_extra_svn_parents($mi_changes, \@parents);
+   if ($self->follow_parent) {
+   my $tickets = $props->{"svk:merge"};
+   if ($tickets) {
+   $self->find_extra_svk_parents($tickets, \@parents);
+   }
+
+   my $mergeinfo_prop = $props->{"svn:mergeinfo"};
+   if ($mergeinfo_prop) {
+   my $mi_changes = $self->mergeinfo_changes(
+   $parent_path,
+   $parent_rev,
+   $self->path,
+   $rev,
+   $mergeinfo_prop);
+   $self->find_extra_svn_parents($mi_changes, \@parents);
+   }
}
 
open my $un, '>>', "$self->{dir}/unhandled.log" or croak $!;
-- 
EW
--
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/3] t0006: rename test-date's "show" to "relative"

2016-06-20 Thread Jeff King 
The "show" tests are really only checking relative formats;
we should make that more clear.

This also frees up the "show" name to later check other
formats. We could later fold "relative" into a more generic
"show" command, but it's not worth it.  Relative times are a
special case already because we have to munge the concept of
"now" in our tests.

Signed-off-by: Jeff King 
---
 t/helper/test-date.c |  8 
 t/t0006-date.sh  | 26 +-
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/t/helper/test-date.c b/t/helper/test-date.c
index 63f3735..8ebcded 100644
--- a/t/helper/test-date.c
+++ b/t/helper/test-date.c
@@ -1,11 +1,11 @@
 #include "cache.h"
 
 static const char *usage_msg = "\n"
-"  test-date show [time_t]...\n"
+"  test-date relative [time_t]...\n"
 "  test-date parse [date]...\n"
 "  test-date approxidate [date]...\n";
 
-static void show_dates(char **argv, struct timeval *now)
+static void show_relative_dates(char **argv, struct timeval *now)
 {
struct strbuf buf = STRBUF_INIT;
 
@@ -61,8 +61,8 @@ int main(int argc, char **argv)
argv++;
if (!*argv)
usage(usage_msg);
-   if (!strcmp(*argv, "show"))
-   show_dates(argv+1, );
+   if (!strcmp(*argv, "relative"))
+   show_relative_dates(argv+1, );
else if (!strcmp(*argv, "parse"))
parse_dates(argv+1, );
else if (!strcmp(*argv, "approxidate"))
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index fac0986..fa05269 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -6,26 +6,26 @@ test_description='test date parsing and printing'
 # arbitrary reference time: 2009-08-30 19:20:00
 TEST_DATE_NOW=125166; export TEST_DATE_NOW
 
-check_show() {
+check_relative() {
t=$(($TEST_DATE_NOW - $1))
echo "$t -> $2" >expect
test_expect_${3:-success} "relative date ($2)" "
-   test-date show $t >actual &&
+   test-date relative $t >actual &&
test_i18ncmp expect actual
"
 }
 
-check_show 5 '5 seconds ago'
-check_show 300 '5 minutes ago'
-check_show 18000 '5 hours ago'
-check_show 432000 '5 days ago'
-check_show 1728000 '3 weeks ago'
-check_show 1300 '5 months ago'
-check_show 3750 '1 year, 2 months ago'
-check_show 55188000 '1 year, 9 months ago'
-check_show 63000 '20 years ago'
-check_show 31449600 '12 months ago'
-check_show 62985600 '2 years ago'
+check_relative 5 '5 seconds ago'
+check_relative 300 '5 minutes ago'
+check_relative 18000 '5 hours ago'
+check_relative 432000 '5 days ago'
+check_relative 1728000 '3 weeks ago'
+check_relative 1300 '5 months ago'
+check_relative 3750 '1 year, 2 months ago'
+check_relative 55188000 '1 year, 9 months ago'
+check_relative 63000 '20 years ago'
+check_relative 31449600 '12 months ago'
+check_relative 62985600 '2 years ago'
 
 check_parse() {
echo "$1 -> $2" >expect
-- 
2.9.0.167.g9e4667c

--
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 0/3] fix local_tzoffset with far-in-future dates

2016-06-20 Thread Jeff King 
On Mon, Jun 20, 2016 at 04:00:12PM -0400, Jeff King wrote:

> You _should_ be able to get the right answer by asking git for
> --date=local, but it doesn't seem to work. Looks like it is because our
> tm_to_time_t hits this code:
> 
>   if (year < 0 || year > 129) /* algo only works for 1970-2099 */
>   return -1;
> 
> and the caller does not actually check the error. The resulting timezone
> is the screwed-up -40643156, which is perhaps how it got into the commit
> in the first place.

So here's a patch to fix that (along with some test infrastructure to
support it). I still don't know how that screwed-up timestamp got _into_
a commit, so perhaps there is another bug lurking.  I couldn't convince
git to parse anything beyond 2100, and committing with
GIT_AUTHOR_DATE='@5758122296 +' works just fine.

  [1/3]: t0006: rename test-date's "show" to "relative"
  [2/3]: t0006: test various date formats
  [3/3]: local_tzoffset: detect errors from tm_to_time_t

-Peff
--
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 3/3] local_tzoffset: detect errors from tm_to_time_t

2016-06-20 Thread Jeff King 
When we want to know the local timezone offset at a given
timestamp, we compute it by asking for localtime() at the
given time, and comparing the offset to GMT at that time.
However, there's some juggling between time_t and "struct
tm" which happens, which involves calling our own
tm_to_time_t().

If that function returns an error (e.g., because it only
handles dates up to the year 2099), it returns "-1", which
we treat as a time_t, and is clearly bogus, leading to
bizarre timestamps (that seem to always adjust the time back
to (time_t)(uint32_t)-1, in the year 2106).

It's not a good idea for local_tzoffset() to simply die
here; it would make it hard to run "git log" on a repository
with funny timestamps. Instead, let's just treat such cases
as "zero offset".

Reported-by: Norbert Kiesel 
Signed-off-by: Jeff King 
---
 date.c  | 2 ++
 t/t0006-date.sh | 5 +
 2 files changed, 7 insertions(+)

diff --git a/date.c b/date.c
index 7c9f769..4c7aa9b 100644
--- a/date.c
+++ b/date.c
@@ -74,6 +74,8 @@ static int local_tzoffset(unsigned long time)
localtime_r(, );
t_local = tm_to_time_t();
 
+   if (t_local == -1)
+   return 0; /* error; just use + */
if (t_local < t) {
eastwest = -1;
offset = t - t_local;
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index 57033dd..04ce535 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -48,6 +48,11 @@ check_show default "$TIME" 'Wed Jun 15 16:13:20 2016 +0200'
 check_show raw "$TIME" '146600 +0200'
 check_show iso-local "$TIME" '2016-06-15 14:13:20 +'
 
+# arbitrary time absurdly far in the future
+FUTURE="5758122296 -0400"
+check_show iso   "$FUTURE" "2152-06-19 18:24:56 -0400"
+check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +"
+
 check_parse() {
echo "$1 -> $2" >expect
test_expect_${4:-success} "parse date ($1${3:+ TZ=$3})" "
-- 
2.9.0.167.g9e4667c
--
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/3] t0006: test various date formats

2016-06-20 Thread Jeff King 
We ended up testing some of these date formats throughout
the rest of the suite (e.g., via for-each-ref's
"$(authordate:...)" format), but we never did so
systematically. t0006 is the right place for unit-testing of
our date-handling code.

Signed-off-by: Jeff King 
---
 t/helper/test-date.c | 26 ++
 t/t0006-date.sh  | 21 +
 2 files changed, 47 insertions(+)

diff --git a/t/helper/test-date.c b/t/helper/test-date.c
index 8ebcded..d9ab360 100644
--- a/t/helper/test-date.c
+++ b/t/helper/test-date.c
@@ -2,6 +2,7 @@
 
 static const char *usage_msg = "\n"
 "  test-date relative [time_t]...\n"
+"  test-date show: [time_t]...\n"
 "  test-date parse [date]...\n"
 "  test-date approxidate [date]...\n";
 
@@ -17,6 +18,29 @@ static void show_relative_dates(char **argv, struct timeval 
*now)
strbuf_release();
 }
 
+static void show_dates(char **argv, const char *format)
+{
+   struct date_mode mode;
+
+   parse_date_format(format, );
+   for (; *argv; argv++) {
+   char *arg = *argv;
+   time_t t;
+   int tz;
+
+   /*
+* Do not use our normal timestamp parsing here, as the point
+* is to test the formatting code in isolation.
+*/
+   t = strtol(arg, , 10);
+   while (*arg == ' ')
+   arg++;
+   tz = atoi(arg);
+
+   printf("%s -> %s\n", *argv, show_date(t, tz, ));
+   }
+}
+
 static void parse_dates(char **argv, struct timeval *now)
 {
struct strbuf result = STRBUF_INIT;
@@ -63,6 +87,8 @@ int main(int argc, char **argv)
usage(usage_msg);
if (!strcmp(*argv, "relative"))
show_relative_dates(argv+1, );
+   else if (skip_prefix(*argv, "show:", ))
+   show_dates(argv+1, x);
else if (!strcmp(*argv, "parse"))
parse_dates(argv+1, );
else if (!strcmp(*argv, "approxidate"))
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index fa05269..57033dd 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -27,6 +27,27 @@ check_relative 63000 '20 years ago'
 check_relative 31449600 '12 months ago'
 check_relative 62985600 '2 years ago'
 
+check_show () {
+   format=$1
+   time=$2
+   expect=$3
+   test_expect_${4:-success} "show date ($format:$time)" '
+   echo "$time -> $expect" >expect &&
+   test-date show:$format "$time" >actual &&
+   test_cmp expect actual
+   '
+}
+
+# arbitrary but sensible time for examples
+TIME='146600 +0200'
+check_show iso8601 "$TIME" '2016-06-15 16:13:20 +0200'
+check_show iso8601-strict "$TIME" '2016-06-15T16:13:20+02:00'
+check_show rfc2822 "$TIME" 'Wed, 15 Jun 2016 16:13:20 +0200'
+check_show short "$TIME" '2016-06-15'
+check_show default "$TIME" 'Wed Jun 15 16:13:20 2016 +0200'
+check_show raw "$TIME" '146600 +0200'
+check_show iso-local "$TIME" '2016-06-15 14:13:20 +'
+
 check_parse() {
echo "$1 -> $2" >expect
test_expect_${4:-success} "parse date ($1${3:+ TZ=$3})" "
-- 
2.9.0.167.g9e4667c

--
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: What's cooking in git.git (Jun 2016, #05; Thu, 16)

2016-06-20 Thread Junio C Hamano 
Torsten Bögershausen  writes:

> There is a conflict in pu:
> "jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"
>
> (And currently pu didn't compile)

Thanks for a report, but didn't I mention this breakage in the
What's cooking report already?
--
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 find commits unique to a branch

2016-06-20 Thread Nikolaus Rath 
Hello,

What's the best way to find all commits in a branch A that have not been
cherry-picked from (or to) another branch B?

I think I could format-patch all commits in every branch into separate
files, hash the Author and Date of each files, and then compare the two
lists. But I'm hoping there's a way to instead have git do the
heavy-lifting?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
--
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: unable to pull from remote if commit date is in the future

2016-06-20 Thread Andreas Schwab 
Norbert Kiesel  writes:

> For the record: the faulty commit is
> https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf

That commit is part of master.  Are you sure you don't have it already?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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: unable to pull from remote if commit date is in the future

2016-06-20 Thread Jeff King 
On Mon, Jun 20, 2016 at 09:49:47PM +0200, Eric Deplagne wrote:

> On Mon, 20 Jun 2016 15:39:28 -0400, Jeff King wrote:
> > On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:
> > 
> > > Hmm.  On closer inspection that commit 23c07cc that github shows with
> > > date 2152-06-19 is already in my local branch.  I got confused because
> > > locally it is shown with a different date: `git log -1 --format='%ci'
> > > 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid.
> > > 
> > > My system is running Debian unstable 64bit.  Is git using the time
> > > rendering methods from the C library (glibc 2.22-12)?
> > 
> > No, git's time code is (mostly) internal routines. Can you show us the
> > output of:
> > 
> > git cat-file commit 23c07cc | egrep '^author|committer'
> > 
> > Note also that some interfaces (like "git log", and GitHub) will show
> > the author date by default, which might be different than the committer
> > date. The "-40643156" timezone definitely looks suspicious, though. I'm
> > curious if it is bad handling in the time code, or if the commit has
> > corrupt ident lines.
> > 
> > -Peff
> 
>   2106 is the year of unsigned 32-bit unix time bug, would there be any 
> relation ?

In an extremely roundabout way, yes. That -40643156 time zone really is
"minus 46 years", but it was generated by _different_ code trying to
compute the author timezone on the fly and using a stray "-1". So I
suspect that no matter what time you ask for in the year 2152 (or
later), the same process would end up with the 2106 time, as the
timezone is custom-computed to end up back at the same error point.

-Peff
--
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: unable to pull from remote if commit date is in the future

2016-06-20 Thread Jeff King 
On Mon, Jun 20, 2016 at 03:46:49PM -0400, Jeff King wrote:

> So to answer my own questions:
> 
>   $ git cat-file commit 23c07cc | egrep '^author|committer'
>   author Sean D'Epagnier  5758122296 -40643156
>   committer Sean D'Epagnier  5758122296 -40643156
> 
> Yes, the timezone really is that ridiculous value. No, the author and
> committer aren't different. According to GNU date, the correct timestamp
> is actually in 2152. Offhand, I'd guess that the timestamp exceeding
> 2^32 is getting converted somewhere inside git to a bogus value, and
> that's how we end up with 2106.

Ah, nope. Everything is working as designed.

5758122296 _is_ in 2152, but that's before we apply the author's
timezone offset. :)

Timezones are supposed to be [+-]HHMM. So the -40643156 timezone is
parsed as -406431 hours, 56 minutes. Which is about 46 years. Hence git
printing 2106.

You _should_ be able to get the right answer by asking git for
--date=local, but it doesn't seem to work. Looks like it is because our
tm_to_time_t hits this code:

  if (year < 0 || year > 129) /* algo only works for 1970-2099 */
return -1;

and the caller does not actually check the error. The resulting timezone
is the screwed-up -40643156, which is perhaps how it got into the commit
in the first place.

-Peff
--
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: unable to pull from remote if commit date is in the future

2016-06-20 Thread Eric Deplagne 
On Mon, 20 Jun 2016 15:39:28 -0400, Jeff King wrote:
> On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:
> 
> > Hmm.  On closer inspection that commit 23c07cc that github shows with
> > date 2152-06-19 is already in my local branch.  I got confused because
> > locally it is shown with a different date: `git log -1 --format='%ci'
> > 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid.
> > 
> > My system is running Debian unstable 64bit.  Is git using the time
> > rendering methods from the C library (glibc 2.22-12)?
> 
> No, git's time code is (mostly) internal routines. Can you show us the
> output of:
> 
> git cat-file commit 23c07cc | egrep '^author|committer'
> 
> Note also that some interfaces (like "git log", and GitHub) will show
> the author date by default, which might be different than the committer
> date. The "-40643156" timezone definitely looks suspicious, though. I'm
> curious if it is bad handling in the time code, or if the commit has
> corrupt ident lines.
> 
> -Peff

  2106 is the year of unsigned 32-bit unix time bug, would there be any 
relation ?

-- 
  Eric Deplagne


signature.asc
Description: Digital signature

Re: [PATCH] perf: accommodate for MacOSX

2016-06-20 Thread Junio C Hamano 
Johannes Schindelin  writes:

> On Sun, 19 Jun 2016, Lars Schneider wrote:
>
>> > On 18 Jun 2016, at 15:03, Johannes Schindelin
>> >  wrote:
>> > 
>> > As this developer has no access to MacOSX developer setups anymore,
>> > Travis becomes the best bet to run performance tests on that OS.
>>
>> We don't run the performance tests on Travis CI right now.
>> Maybe we should? With your patch below it should work, right?
> ...
>
> Yeah, well, I should have been clearer in my commit message: this patch
> allows the perf tests to *run*, not to *pass*... ;-)

OK, Lars, do we still want to take this patch?  I am leaning towards
taking it, if only to motivate interested others with OS X to look
into making the perf tests to actually run.
--
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: unable to pull from remote if commit date is in the future

2016-06-20 Thread Jeff King 
On Mon, Jun 20, 2016 at 03:39:28PM -0400, Jeff King wrote:

> On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:
> 
> > Hmm.  On closer inspection that commit 23c07cc that github shows with
> > date 2152-06-19 is already in my local branch.  I got confused because
> > locally it is shown with a different date: `git log -1 --format='%ci'
> > 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid.
> > 
> > My system is running Debian unstable 64bit.  Is git using the time
> > rendering methods from the C library (glibc 2.22-12)?
> 
> No, git's time code is (mostly) internal routines. Can you show us the
> output of:
> 
> git cat-file commit 23c07cc | egrep '^author|committer'
> 
> Note also that some interfaces (like "git log", and GitHub) will show
> the author date by default, which might be different than the committer
> date. The "-40643156" timezone definitely looks suspicious, though. I'm
> curious if it is bad handling in the time code, or if the commit has
> corrupt ident lines.

Actually, I just noticed in your earlier message a link to the public
GitHub repository.

So to answer my own questions:

  $ git cat-file commit 23c07cc | egrep '^author|committer'
  author Sean D'Epagnier  5758122296 -40643156
  committer Sean D'Epagnier  5758122296 -40643156

Yes, the timezone really is that ridiculous value. No, the author and
committer aren't different. According to GNU date, the correct timestamp
is actually in 2152. Offhand, I'd guess that the timestamp exceeding
2^32 is getting converted somewhere inside git to a bogus value, and
that's how we end up with 2106.

-Peff
--
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: unable to pull from remote if commit date is in the future

2016-06-20 Thread Norbert Kiesel 
On Mon, Jun 20, 2016 at 12:39 PM, Jeff King  wrote:
> git cat-file commit 23c07cc | egrep '^author|committer'

author Sean D'Epagnier  5758122296 -40643156
committer Sean D'Epagnier  5758122296 -40643156

date --date='@5758122296' returns "Mon Jun 19 15:24:56 PDT 2152" which
is what is shown by github.
--
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: unable to pull from remote if commit date is in the future

2016-06-20 Thread Jeff King 
On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:

> Hmm.  On closer inspection that commit 23c07cc that github shows with
> date 2152-06-19 is already in my local branch.  I got confused because
> locally it is shown with a different date: `git log -1 --format='%ci'
> 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid.
> 
> My system is running Debian unstable 64bit.  Is git using the time
> rendering methods from the C library (glibc 2.22-12)?

No, git's time code is (mostly) internal routines. Can you show us the
output of:

git cat-file commit 23c07cc | egrep '^author|committer'

Note also that some interfaces (like "git log", and GitHub) will show
the author date by default, which might be different than the committer
date. The "-40643156" timezone definitely looks suspicious, though. I'm
curious if it is bad handling in the time code, or if the commit has
corrupt ident lines.

-Peff
--
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] Make find_commit_subject() more robust

2016-06-20 Thread Junio C Hamano 
Johannes Schindelin  writes:

> Just like the pretty printing machinery, we should simply ignore empty
> lines at the beginning of the commit messages.
>
> This discrepancy was noticed when an early version of the rebase--helper
> produced commit objects with more than one empty line between the header
> and the commit message.
>
> Signed-off-by: Johannes Schindelin 
> ---
> Published-As: https://github.com/dscho/git/releases/tag/leading-empty-lines-v1
>
>   And another patch from the rebase--helper front. I guess I'll
>   call it a day with this one.

Makes sense.  This has a trivial textual conflict with cleanup
patches in flight, I think, but that is not a big problem.  It does
hint that we might want to find a library function that can replace
a hand-rolled while loop we are adding here, though ;-)

Perhaps cast this new behaviour in stone by adding a test?

Thanks.

>  commit.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/commit.c b/commit.c
> index 3f4f371..7b00989 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -415,6 +415,8 @@ int find_commit_subject(const char *commit_buffer, const 
> char **subject)
>   p++;
>   if (*p) {
>   p += 2;
> + while (*p == '\n')
> + p++;
>   for (eol = p; *eol && *eol != '\n'; eol++)
>   ; /* do nothing */
>   } else
--
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 7/7] format-patch: use stdout directly

2016-06-20 Thread Junio C Hamano 
Johannes Schindelin  writes:

> Earlier, we freopen()ed stdout in order to write patches to files.
> That forced us to duplicate stdout (naming it "realstdout") because we
> *still* wanted to be able to report the file names.
>
> As we do not abuse stdout that way anymore, we no longer need to
> duplicate stdout, either.
>
> Signed-off-by: Johannes Schindelin 
> ---
>  builtin/log.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)

Overall, it was a pleasant read, modulo some details that I
mentioned separately elsewhere, i.e.

 - we do not need to lose flush-or-die
 - we do not need to lose --color=always
 - we do not need to lose macro-ness of putchar()

Thanks.

>
> diff --git a/builtin/log.c b/builtin/log.c
> index db034a8..5a889d5 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -796,7 +796,6 @@ static int git_format_config(const char *var, const char 
> *value, void *cb)
>   return git_log_config(var, value, cb);
>  }
>  
> -static FILE *realstdout = NULL;
>  static const char *output_directory = NULL;
>  static int outdir_offset;
>  
> @@ -822,7 +821,7 @@ static int open_next_file(struct commit *commit, const 
> char *subject,
>   fmt_output_subject(, subject, rev);
>  
>   if (!quiet)
> - fprintf(realstdout, "%s\n", filename.buf + outdir_offset);
> + printf("%s\n", filename.buf + outdir_offset);
>  
>   if ((rev->diffopt.file = fopen(filename.buf, "w")) == NULL)
>   return error(_("Cannot open patch file %s"), filename.buf);
> @@ -1629,9 +1628,6 @@ int cmd_format_patch(int argc, const char **argv, const 
> char *prefix)
>   get_patch_ids(, );
>   }
>  
> - if (!use_stdout)
> - realstdout = xfdopen(xdup(1), "w");
> -
>   if (prepare_revision_walk())
>   die(_("revision walk setup failed"));
>   rev.boundary = 1;
--
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 1/1] mingw: work around t2300's assuming non-Windows paths

2016-06-20 Thread Junio C Hamano 
Johannes Schindelin  writes:

> On Windows, we have to juggle two different schemes of representing
> paths: the native, Windows paths (the only ones known to the main
> Git executable) on the one hand, and POSIX-ish ones used by the Bash
> through MSYS2's POSIX emulation layer on the other hand.
>
> A Windows path looks like this: C:\git-sdk-64\usr\src\git. In modern
> Windows, it is almost always legal to use forward slashes as directory
> separators, which is the reason why the Git executable itself would use
> the path C:/git-sdk-64/usr/src/git instead. The equivalent POSIX-ish
> path would be: /c/git-sdk-64/usr/src/git.
>
> This patch works around the assumption of t2300-cd-to-toplevel.sh that
> `git --exec-path` spits out a POSIX-ish path, by converting the output
> accordingly.

Hmm, I am confused.  `git --exec-path` _is_ meant to "spit out" a
path that is usable when prepended/appended to $PATH [1], and it
does _not_ have to be POSIX-ish path.  It is totally up to the port
to adjust it to the platform's convention how the $PATH environment
variable is understood.

If $PATH cannot take C:/git-sdk-64/usr/src/git but does understand
/c/git-sdk-64/usr/src/git, perhaps "git --exec-path" should be
emitting the latter in the first place?


[Footnote]

*1* That after all was how we handled the painful 1.6 "'git-cmd' to
'git cmd'" transition (cf. $gmane/93793).



> Signed-off-by: Johannes Schindelin 
> ---
>  t/t2300-cd-to-toplevel.sh | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
> index cccd7d9..c8de6d8 100755
> --- a/t/t2300-cd-to-toplevel.sh
> +++ b/t/t2300-cd-to-toplevel.sh
> @@ -4,11 +4,19 @@ test_description='cd_to_toplevel'
>  
>  . ./test-lib.sh
>  
> +EXEC_PATH="$(git --exec-path)"
> +test_have_prereq !MINGW ||
> +case "$EXEC_PATH" in
> +[A-Za-z]:/*)
> + EXEC_PATH="/${EXEC_PATH%%:*}${EXEC_PATH#?:}"
> + ;;
> +esac
> +
>  test_cd_to_toplevel () {
>   test_expect_success $3 "$2" '
>   (
>   cd '"'$1'"' &&
> - PATH="$(git --exec-path):$PATH" &&
> + PATH="$EXEC_PATH:$PATH" &&
>   . git-sh-setup &&
>   cd_to_toplevel &&
>   [ "$(pwd -P)" = "$TOPLEVEL" ]
--
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: unable to pull from remote if commit date is in the future

2016-06-20 Thread Stefan Beller 
On Mon, Jun 20, 2016 at 11:41 AM, Norbert Kiesel  wrote:
> Hi,
>
> I'm following an upstream repo on github.  Today morning I saw a new
> commit there, but a `git pull` in my clone did not fetch it and
> instead said "Already up-to-date.".  On closer inspection, github
> reports commit time as 2152-06-19. The same project has some other
> commits with commit time in the future that were fetched.  My guess is
> that happened when those commits got a child with commit date in the
> past.

git-pull doesn't care about the commit/author date/time at all.

All it takes into consideration
is the graph structure of the commits on the local and the remote branch,
i.e. Are there any commits on the remote branch that are not part of the local
branch history?


>
> Is there any way to force git pulling that request?  (Perhaps I should
> try to tell git that it's really 2152?)

You need to see if that commit is part of the history of the
remote branch you pulled.

>
> For the record: the faulty commit is
> https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf
> --
> 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
--
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] mingw: let the build succeed with DEVELOPER=1

2016-06-20 Thread Junio C Hamano 
Johannes Schindelin  writes:

> The recently introduced developer flags identified a couple of
> old-style function declarations in the Windows-specific code where
> the parameter list was left empty instead of specifying "void"
> explicitly. Let's just fix them.

Thanks.  It's about time for them to be cleaned up.

Will queue.

>
> Signed-off-by: Johannes Schindelin 
> ---
>
>   This came up when working on the rebase--helper changes.
>
> Published-As: https://github.com/dscho/git/releases/tag/mingw-dev-flags-v1
>  compat/mingw.c   | 6 +++---
>  compat/mingw.h   | 4 ++--
>  compat/winansi.c | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index a8218e6..2b5467d 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -2162,7 +2162,7 @@ int xwcstoutf(char *utf, const wchar_t *wcs, size_t 
> utflen)
>   return -1;
>  }
>  
> -static void setup_windows_environment()
> +static void setup_windows_environment(void)
>  {
>   char *tmp = getenv("TMPDIR");
>  
> @@ -2204,7 +2204,7 @@ typedef struct {
>  extern int __wgetmainargs(int *argc, wchar_t ***argv, wchar_t ***env, int 
> glob,
>   _startupinfo *si);
>  
> -static NORETURN void die_startup()
> +static NORETURN void die_startup(void)
>  {
>   fputs("fatal: not enough memory for initialization", stderr);
>   exit(128);
> @@ -2224,7 +2224,7 @@ static char *wcstoutfdup_startup(char *buffer, const 
> wchar_t *wcs, size_t len)
>   return memcpy(malloc_startup(len), buffer, len);
>  }
>  
> -void mingw_startup()
> +void mingw_startup(void)
>  {
>   int i, maxlen, argc;
>   char *buffer;
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 69bb43d..9a8803b 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -532,8 +532,8 @@ extern CRITICAL_SECTION pinfo_cs;
>   * A replacement of main() that adds win32 specific initialization.
>   */
>  
> -void mingw_startup();
> -#define main(c,v) dummy_decl_mingw_main(); \
> +void mingw_startup(void);
> +#define main(c,v) dummy_decl_mingw_main(void); \
>  static int mingw_main(c,v); \
>  int main(int argc, char **argv) \
>  { \
> diff --git a/compat/winansi.c b/compat/winansi.c
> index 3be60ce..db4a5b0 100644
> --- a/compat/winansi.c
> +++ b/compat/winansi.c
> @@ -492,7 +492,7 @@ static inline ioinfo* _pioinfo(int fd)
>   (fd & (IOINFO_ARRAY_ELTS - 1)) * sizeof_ioinfo);
>  }
>  
> -static int init_sizeof_ioinfo()
> +static int init_sizeof_ioinfo(void)
>  {
>   int istty, wastty;
>   /* don't init twice */
--
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: unable to pull from remote if commit date is in the future

2016-06-20 Thread Norbert Kiesel 
Hmm.  On closer inspection that commit 23c07cc that github shows with
date 2152-06-19 is already in my local branch.  I got confused because
locally it is shown with a different date: `git log -1 --format='%ci'
23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid.

My system is running Debian unstable 64bit.  Is git using the time
rendering methods from the C library (glibc 2.22-12)?

On Mon, Jun 20, 2016 at 11:46 AM, Stefan Beller  wrote:
> On Mon, Jun 20, 2016 at 11:41 AM, Norbert Kiesel  wrote:
>> Hi,
>>
>> I'm following an upstream repo on github.  Today morning I saw a new
>> commit there, but a `git pull` in my clone did not fetch it and
>> instead said "Already up-to-date.".  On closer inspection, github
>> reports commit time as 2152-06-19. The same project has some other
>> commits with commit time in the future that were fetched.  My guess is
>> that happened when those commits got a child with commit date in the
>> past.
>
> git-pull doesn't care about the commit/author date/time at all.
>
> All it takes into consideration
> is the graph structure of the commits on the local and the remote branch,
> i.e. Are there any commits on the remote branch that are not part of the local
> branch history?
>
>
>>
>> Is there any way to force git pulling that request?  (Perhaps I should
>> try to tell git that it's really 2152?)
>
> You need to see if that commit is part of the history of the
> remote branch you pulled.
>
>>
>> For the record: the faulty commit is
>> https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf
>> --
>> 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
--
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

unable to pull from remote if commit date is in the future

2016-06-20 Thread Norbert Kiesel 
Hi,

I'm following an upstream repo on github.  Today morning I saw a new
commit there, but a `git pull` in my clone did not fetch it and
instead said "Already up-to-date.".  On closer inspection, github
reports commit time as 2152-06-19. The same project has some other
commits with commit time in the future that were fetched.  My guess is
that happened when those commits got a child with commit date in the
past.

Is there any way to force git pulling that request?  (Perhaps I should
try to tell git that it's really 2152?)

For the record: the faulty commit is
https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf
--
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 --shallow-submodules option

2016-06-20 Thread Stefan Beller 
On Mon, Jun 20, 2016 at 6:06 AM, Istvan Zakar  wrote:
> Hello,
>
> I'm working on a relatively big project with many submodules. During
> cloning for testing I tried to decrease the amount of data need to be
> fetched from the server by using --shallow-submodules option in the clone
> command. It seems to check out the tip of the remote repo, and if it's not
> the commit registered in the superproject the submodule update fails
> (obviously).

Yes that is broken as the depth of a submodule is counted from its own HEAD
not from the superprojects sha1 as it should.

So it does

git clone --depth=1  

if HEAD != recorded gitlink sha1,
git fetch 

git checkout 

> Can I somehow tell to fetch that exact commit I need for my
> superproject?

Some servers support fetching by direct sha1, which is what we make use
of here, then it sort-of works.

If the server doesn't support the capability to fetch an arbitrary sha1,
the submodule command fails, with a message such as

error: no such remote ref $sha1
Fetched in submodule path '', but it did not contain
$sha1. Direct fetching of that commit failed.

So if it breaks for you now, I would suggest not using that switch, I
don't think there is a quick
workaround.

>
> Thanks,
>Istvan

Thanks,
Stefan

>
> --
> 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
--
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] shallow clone to not imply shallow submodules

2016-06-20 Thread Jeff King 
On Mon, Jun 20, 2016 at 09:59:58AM -0700, Stefan Beller wrote:

> Signed-off-by: Stefan Beller 
> ---
> 
> Hi Junio, Peff,
> 
> I thought about this patch squashed into  
> "clone: do not let --depth imply --shallow-submodules" will actually test
> for the regression.

Yep, it looks good to me.

> +test_expect_success 'shallow clone does not imply shallow submodule' '
> + test_when_finished "rm -rf super_clone" &&
> + git clone --recurse-submodules --depth 2 "file://$pwd/." super_clone &&
> + (
> + cd super_clone &&
> + git log --oneline >lines &&
> + test_line_count = 2 lines
> + ) &&
> + (
> + cd super_clone/sub &&
> + git log --oneline >lines &&
> + test_line_count = 3 lines
> + )
> +'

This follows the style of the other tests, so it's the right thing here.
But as a style suggestion, I think:

  git -C super_clone/sub log --oneline >lines &&
  test_line_count = 3 lines

is nicer than the subshell. It's more succinct, and it saves a process.

-Peff
--
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] t5614: don't use subshells

2016-06-20 Thread Stefan Beller 
Using a subshell for just one git command is both a waste in compute
overhead (create a new process) as well as in line count.

Suggested-by: Jeff King 
Signed-off-by: Stefan Beller 
---

 Junio,

 This goes on top of the patch that I just sent
 "[PATCH] shallow clone to not imply shallow submodules" (which is to
 be squashed into "clone: do not let --depth imply --shallow-submodules".
 
 Unlike the prior patch we would not want this patch to fall through
 to origin/maint fast, but allow cooking?
 
 Thanks,
 Stefan

 t/t5614-clone-submodules.sh | 70 +
 1 file changed, 20 insertions(+), 50 deletions(-)

diff --git a/t/t5614-clone-submodules.sh b/t/t5614-clone-submodules.sh
index a9aaa01..da2a67f 100755
--- a/t/t5614-clone-submodules.sh
+++ b/t/t5614-clone-submodules.sh
@@ -25,76 +25,46 @@ test_expect_success 'setup' '
 test_expect_success 'nonshallow clone implies nonshallow submodule' '
test_when_finished "rm -rf super_clone" &&
git clone --recurse-submodules "file://$pwd/." super_clone &&
-   (
-   cd super_clone &&
-   git log --oneline >lines &&
-   test_line_count = 3 lines
-   ) &&
-   (
-   cd super_clone/sub &&
-   git log --oneline >lines &&
-   test_line_count = 3 lines
-   )
+   git -C super_clone log --oneline >lines &&
+   test_line_count = 3 lines &&
+   git -C super_clone/sub log --oneline >lines &&
+   test_line_count = 3 lines
 '
 
 test_expect_success 'shallow clone with shallow submodule' '
test_when_finished "rm -rf super_clone" &&
git clone --recurse-submodules --depth 2 --shallow-submodules 
"file://$pwd/." super_clone &&
-   (
-   cd super_clone &&
-   git log --oneline >lines &&
-   test_line_count = 2 lines
-   ) &&
-   (
-   cd super_clone/sub &&
-   git log --oneline >lines &&
-   test_line_count = 1 lines
-   )
+   git -C super_clone log --oneline >lines &&
+   test_line_count = 2 lines &&
+   git -C super_clone/sub log --oneline >lines &&
+   test_line_count = 1 lines
 '
 
 test_expect_success 'shallow clone does not imply shallow submodule' '
test_when_finished "rm -rf super_clone" &&
git clone --recurse-submodules --depth 2 "file://$pwd/." super_clone &&
-   (
-   cd super_clone &&
-   git log --oneline >lines &&
-   test_line_count = 2 lines
-   ) &&
-   (
-   cd super_clone/sub &&
-   git log --oneline >lines &&
-   test_line_count = 3 lines
-   )
+   git -C super_clone log --oneline >lines &&
+   test_line_count = 2 lines &&
+   git -C super_clone/sub log --oneline >lines &&
+   test_line_count = 3 lines
 '
 
 test_expect_success 'shallow clone with non shallow submodule' '
test_when_finished "rm -rf super_clone" &&
git clone --recurse-submodules --depth 2 --no-shallow-submodules 
"file://$pwd/." super_clone &&
-   (
-   cd super_clone &&
-   git log --oneline >lines &&
-   test_line_count = 2 lines
-   ) &&
-   (
-   cd super_clone/sub &&
-   git log --oneline >lines &&
-   test_line_count = 3 lines
-   )
+   git -C super_clone log --oneline >lines &&
+   test_line_count = 2 lines &&
+   git -C super_clone/sub log --oneline >lines &&
+   test_line_count = 3 lines
 '
 
 test_expect_success 'non shallow clone with shallow submodule' '
test_when_finished "rm -rf super_clone" &&
git clone --recurse-submodules --no-local --shallow-submodules 
"file://$pwd/." super_clone &&
-   (
-   cd super_clone &&
-   git log --oneline >lines &&
-   test_line_count = 3 lines
-   ) &&
-   (
-   cd super_clone/sub &&
-   git log --oneline >lines &&
-   test_line_count = 1 lines
-   )
+   git -C super_clone log --oneline >lines &&
+   test_line_count = 3 lines &&
+   git -C super_clone/sub log --oneline >lines &&
+   test_line_count = 1 lines
 '
 
 test_done
-- 
2.7.0.rc0.40.g5328432.dirty

--
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] shallow clone to not imply shallow submodules

2016-06-20 Thread Jeff King 
On Mon, Jun 20, 2016 at 10:14:47AM -0700, Stefan Beller wrote:

> > This follows the style of the other tests, so it's the right thing here.
> > But as a style suggestion, I think:
> >
> >   git -C super_clone/sub log --oneline >lines &&
> >   test_line_count = 3 lines
> >
> > is nicer than the subshell. It's more succinct, and it saves a process.
> 
> which we would want to refactor to in a follow up, but not merge it
> through to 2.9.1.

Yeah, exactly. That was what I meant by "here".

-Peff
--
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] shallow clone to not imply shallow submodules

2016-06-20 Thread Stefan Beller 
On Mon, Jun 20, 2016 at 10:13 AM, Jeff King  wrote:
> On Mon, Jun 20, 2016 at 09:59:58AM -0700, Stefan Beller wrote:
>
>> Signed-off-by: Stefan Beller 
>> ---
>>
>> Hi Junio, Peff,
>>
>> I thought about this patch squashed into
>> "clone: do not let --depth imply --shallow-submodules" will actually test
>> for the regression.
>
> Yep, it looks good to me.
>
>> +test_expect_success 'shallow clone does not imply shallow submodule' '
>> + test_when_finished "rm -rf super_clone" &&
>> + git clone --recurse-submodules --depth 2 "file://$pwd/." super_clone &&
>> + (
>> + cd super_clone &&
>> + git log --oneline >lines &&
>> + test_line_count = 2 lines
>> + ) &&
>> + (
>> + cd super_clone/sub &&
>> + git log --oneline >lines &&
>> + test_line_count = 3 lines
>> + )
>> +'
>
> This follows the style of the other tests, so it's the right thing here.
> But as a style suggestion, I think:
>
>   git -C super_clone/sub log --oneline >lines &&
>   test_line_count = 3 lines
>
> is nicer than the subshell. It's more succinct, and it saves a process.

which we would want to refactor to in a follow up, but not merge it
through to 2.9.1.

Thanks,
Stefan

>
> -Peff
--
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 1/7] log-tree: respect diffopt's configured output file stream

2016-06-20 Thread Junio C Hamano 
Johannes Schindelin  writes:

> The diff options already know how to print the output anywhere else
> than stdout. The same is needed for log output in general, e.g.
> when writing patches to files in `git format-patch`. Let's allow
> users to use log_tree_commit() *without* changing global state via
> freopen().

I wonder if this change is actually fixing existing bugs.  Are there
cases where diffopt.file is set, i.e. the user expects the output to
be sent elsewhere, but the code here unconditionally emits to the
standard output?  I suspect that such a bug can be demonstratable in
a test or two, if that were the case.

I am sort-of surprised that we didn't do this already even though we
had diffopt.file for a long time since c0c77734 (Write diff output
to a file in struct diff_options, 2008-03-09).

Use of freopen() to always write patches through stdout may have
been done as a lazy workaround of the issue this patch fixes, but
what is surprising to me is that doing it the right way like this
patch does is not that much of work.  Perhaps that was done long
before c0c77734 was done, which would mean doing it the right way
back then when we started using freopen() it would have been a lot
more work and we thought taking a short-cut was warranted.

In any case, this is a change in the good direction.  Thanks for
cleaning things up.

>   if (opt->children.name)
>   show_children(opt, commit, abbrev_commit);
>   show_decorations(opt, commit);
>   if (opt->graph && !graph_is_commit_finished(opt->graph)) {
> - putchar('\n');
> + fputc('\n', opt->diffopt.file);

Hmph.  putc() is the "to the given stream" equivalent of putchar()
in the "send to stdout" world, not fputc().  I do not see a reason
to force the call to go to a function avoiding a possible macro here.

Likewise for all the new fputc() calls in this series that were
originally putchar().

> @@ -880,8 +880,9 @@ int log_tree_commit(struct rev_info *opt, struct commit 
> *commit)
>   shown = 1;
>   }
>   if (opt->track_linear && !opt->linear && opt->reverse_output_stage)
> - printf("\n%s\n", opt->break_bar);
> + fprintf(opt->diffopt.file, "\n%s\n", opt->break_bar);
>   opt->loginfo = NULL;
> - maybe_flush_or_die(stdout, "stdout");
> + if (opt->diffopt.file == stdout)
> + maybe_flush_or_die(stdout, "stdout");
>   return shown;
>  }

This one looks fishy.

Back when we freopen()'ed to write patches only through stdout, we
always called maybe_flush_or_die() to make sure that the output is
flushed correctly after processing each commit.  This change makes
it not to care, which I doubt was what you intended.  Instead, my
suspicion is that you didn't want to say "stdout" when writing into
a file.

But even when writing to on-disk files, the code before your series
would have said "stdout" when it had trouble flushing, so I do not
think this new "if()" condition is making things better.  If "it
said stdout when having trouble flushing to a file" were a problem
to be fixed, "let's not say stdout by not even attempting to flush
and catch errors when writing to a file" would not be the right
solution, no?

Personally, I do not think it hurts if we kept saying 'stdout' here,
even when we flush opt->diffopt.file and found a problem.

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: Short-term plans for the post 2.9 cycle

2016-06-20 Thread Junio C Hamano 
On Mon, Jun 20, 2016 at 9:46 AM, Stefan Beller  wrote:
> On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano  wrote:
>> Here are the list of topics that are in the "private edition" I use
>> for every day work, grouped by where they sit in the the near-term
>> plan of merging them up to 'next' and then to 'master'.
>>
>> These will be merged to 'master' soonish.
>>
>
> Thanks for such an overview!

FYI, this can be obtained by running "git log --oneline --first-parent
master..pu".
The point where "Merge ... into jch" ends is what I usually use myself
(IOW, I do
attempt to build and test 'pu', but I do not run it regularly).
--
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] shallow clone to not imply shallow submodules

2016-06-20 Thread Stefan Beller 
Signed-off-by: Stefan Beller 
---

Hi Junio, Peff,

I thought about this patch squashed into  
"clone: do not let --depth imply --shallow-submodules" will actually test
for the regression.

Thanks,
Stefan

 t/t5614-clone-submodules.sh | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/t/t5614-clone-submodules.sh b/t/t5614-clone-submodules.sh
index f7c630b..a9aaa01 100755
--- a/t/t5614-clone-submodules.sh
+++ b/t/t5614-clone-submodules.sh
@@ -37,7 +37,7 @@ test_expect_success 'nonshallow clone implies nonshallow 
submodule' '
)
 '
 
-test_expect_success 'shallow clone does not imply shallow submodule' '
+test_expect_success 'shallow clone with shallow submodule' '
test_when_finished "rm -rf super_clone" &&
git clone --recurse-submodules --depth 2 --shallow-submodules 
"file://$pwd/." super_clone &&
(
@@ -52,6 +52,21 @@ test_expect_success 'shallow clone does not imply shallow 
submodule' '
)
 '
 
+test_expect_success 'shallow clone does not imply shallow submodule' '
+   test_when_finished "rm -rf super_clone" &&
+   git clone --recurse-submodules --depth 2 "file://$pwd/." super_clone &&
+   (
+   cd super_clone &&
+   git log --oneline >lines &&
+   test_line_count = 2 lines
+   ) &&
+   (
+   cd super_clone/sub &&
+   git log --oneline >lines &&
+   test_line_count = 3 lines
+   )
+'
+
 test_expect_success 'shallow clone with non shallow submodule' '
test_when_finished "rm -rf super_clone" &&
git clone --recurse-submodules --depth 2 --no-shallow-submodules 
"file://$pwd/." super_clone &&
-- 
2.7.0.rc0.40.g5328432.dirty

--
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: Short-term plans for the post 2.9 cycle

2016-06-20 Thread Stefan Beller 
On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano  wrote:
> Here are the list of topics that are in the "private edition" I use
> for every day work, grouped by where they sit in the the near-term
> plan of merging them up to 'next' and then to 'master'.
>
> These will be merged to 'master' soonish.
>

Thanks for such an overview!
--
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 5/5] format-patch: avoid freopen()

2016-06-20 Thread Junio C Hamano 
Johannes Schindelin  writes:

> When format-patch calls the diff machinery, want_color() is used to
> determine whether to use ANSI color sequences or not. If use_color is not
> set explicitly, isatty(1) is used to determine whether or not the user
> wants color. When stdout was freopen()ed, this isatty(1) call naturally
> looked at the file descriptor that was reopened, and determined correctly
> that no color was desired.
>
> With the freopen() call gone, stdout may very well be the terminal. But we
> still do not want color because the output is intended to go to a file (at
> least if output_directory is set).

How does this interact with --color=... that is given from the
command line at the same time?  Currently --color=always would
give you a coloured output.

I personally do not think of a sensible reason why anybody wants a
colored format-patch output, but Git's userbase has grown large
enough and you can no longer expect that only sensible people use it
;-)

You can probably sell "when giving out put to file, we will never
color the output" as an improved new world order, but if that is
what this change wants to do, it probably deserves a separate patch.

I however think you can avoid breaking expectations by people who
are not so sensible by overriding only when use_color is set to
GIT_COLOR_AUTO, perhaps?
--
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/8] object_id part 4

2016-06-20 Thread Junio C Hamano 
Jeff King  writes:

> I am on the fence regarding oidcpy/oidclr. I agree they _could_ be
> struct assignments, but it is also convenient to have concept wrapped up
> in a function, in case we ever want to do anything more complicated.

Also dedicated functions have documenation value.  There are some
things that currently use the same 40-hex that is the result of
running SHA-1 but are not object names (e.g.  patch id, and rerere
id).  They use the same hashcpy()/hashcmp() helpers as object names
do, but the code that use them probably do not want to be converted
to struct oid and oidcpy().

--
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 stash doesn't always save work dir as-is: bug?

2016-06-20 Thread Mathieu Giorgino 
Is there a reason this e-mail never received an answer ?

http://permalink.gmane.org/gmane.comp.version-control.git/234153

Isn't this a bug ?

Thanks,

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

Problem with --shallow-submodules option

2016-06-20 Thread Istvan Zakar 
Hello,

I'm working on a relatively big project with many submodules. During 
cloning for testing I tried to decrease the amount of data need to be 
fetched from the server by using --shallow-submodules option in the clone 
command. It seems to check out the tip of the remote repo, and if it's not 
the commit registered in the superproject the submodule update fails 
(obviously). Can I somehow tell to fetch that exact commit I need for my 
superproject?

Thanks,
   Istvan

--
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/7] Let log-tree and friends respect diffopt's `file` field

2016-06-20 Thread Johannes Schindelin 
Hi,

[sorry, Eric, forgot to Cc: you on the cover letter...]

On Mon, 20 Jun 2016, Johannes Schindelin wrote:

> Johannes Schindelin (7):
>   log-tree: respect diffopt's configured output file stream
>   line-log: respect diffopt's configured output file stream
>   graph: respect the diffopt.file setting
>   shortlog: support outputting to streams other than stdout
>   format-patch: explicitly switch off color when writing to files
>   format-patch: avoid freopen()
>   format-patch: use stdout directly

The interdiff is empty: all I did was to split out the first and the third
`format-patch:` commit, to leave really only the relevant part in the
"avoid freopen()" commit.

Ciao,
Dscho
--
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

With Good Faith...

2016-06-20 Thread ude 1959 
Dear Sir/Madam

Please I am not in a hurry but let us use the same heart.

Best Regards,

Mr. Udeij Haid


Please I am Very Sorry To Take A bit Of Your Time. Regards..docx
Description: MS-Word 2007 document

[PATCH v2 6/7] format-patch: avoid freopen()

2016-06-20 Thread Johannes Schindelin 
We just taught the relevant functions to respect the diffopt.file field,
to allow writing somewhere else than stdout. Let's make use of it.

Technically, we do not need to avoid that call in a builtin: we assume
that builtins (as opposed to library functions) are stand-alone programs
that may do with their (global) state. Yet, we want to be able to reuse
that code in properly lib-ified code, e.g. when converting scripts into
builtins.

Further, while we did not *have* to touch the cmd_show() and cmd_cherry()
code paths (because they do not want to write anywhere but stdout as of
yet), it just makes sense to be consistent, making it easier and safer to
move the code later.

Signed-off-by: Johannes Schindelin 
---
 builtin/log.c | 64 ++-
 1 file changed, 33 insertions(+), 31 deletions(-)

diff --git a/builtin/log.c b/builtin/log.c
index abd889b..db034a8 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -236,7 +236,7 @@ static void show_early_header(struct rev_info *rev, const 
char *stage, int nr)
if (rev->commit_format != CMIT_FMT_ONELINE)
putchar(rev->diffopt.line_termination);
}
-   printf(_("Final output: %d %s\n"), nr, stage);
+   fprintf(rev->diffopt.file, _("Final output: %d %s\n"), nr, stage);
 }
 
 static struct itimerval early_output_timer;
@@ -445,7 +445,7 @@ static void show_tagger(char *buf, int len, struct rev_info 
*rev)
pp.fmt = rev->commit_format;
pp.date_mode = rev->date_mode;
pp_user_info(, "Tagger", , buf, get_log_output_encoding());
-   printf("%s", out.buf);
+   fprintf(rev->diffopt.file, "%s", out.buf);
strbuf_release();
 }
 
@@ -456,7 +456,7 @@ static int show_blob_object(const unsigned char *sha1, 
struct rev_info *rev, con
char *buf;
unsigned long size;
 
-   fflush(stdout);
+   fflush(rev->diffopt.file);
if (!DIFF_OPT_TOUCHED(>diffopt, ALLOW_TEXTCONV) ||
!DIFF_OPT_TST(>diffopt, ALLOW_TEXTCONV))
return stream_blob_to_fd(1, sha1, NULL, 0);
@@ -496,7 +496,7 @@ static int show_tag_object(const unsigned char *sha1, 
struct rev_info *rev)
}
 
if (offset < size)
-   fwrite(buf + offset, size - offset, 1, stdout);
+   fwrite(buf + offset, size - offset, 1, rev->diffopt.file);
free(buf);
return 0;
 }
@@ -505,7 +505,8 @@ static int show_tree_object(const unsigned char *sha1,
struct strbuf *base,
const char *pathname, unsigned mode, int stage, void *context)
 {
-   printf("%s%s\n", pathname, S_ISDIR(mode) ? "/" : "");
+   FILE *file = context;
+   fprintf(file, "%s%s\n", pathname, S_ISDIR(mode) ? "/" : "");
return 0;
 }
 
@@ -565,7 +566,7 @@ int cmd_show(int argc, const char **argv, const char 
*prefix)
 
if (rev.shown_one)
putchar('\n');
-   printf("%stag %s%s\n",
+   fprintf(rev.diffopt.file, "%stag %s%s\n",
diff_get_color_opt(, 
DIFF_COMMIT),
t->tag,
diff_get_color_opt(, 
DIFF_RESET));
@@ -584,12 +585,12 @@ int cmd_show(int argc, const char **argv, const char 
*prefix)
case OBJ_TREE:
if (rev.shown_one)
putchar('\n');
-   printf("%stree %s%s\n\n",
+   fprintf(rev.diffopt.file, "%stree %s%s\n\n",
diff_get_color_opt(, 
DIFF_COMMIT),
name,
diff_get_color_opt(, 
DIFF_RESET));
read_tree_recursive((struct tree *)o, "", 0, 0, 
_all,
-   show_tree_object, NULL);
+   show_tree_object, rev.diffopt.file);
rev.shown_one = 1;
break;
case OBJ_COMMIT:
@@ -799,7 +800,7 @@ static FILE *realstdout = NULL;
 static const char *output_directory = NULL;
 static int outdir_offset;
 
-static int reopen_stdout(struct commit *commit, const char *subject,
+static int open_next_file(struct commit *commit, const char *subject,
 struct rev_info *rev, int quiet)
 {
struct strbuf filename = STRBUF_INIT;
@@ -823,7 +824,7 @@ static int reopen_stdout(struct commit *commit, const char 
*subject,
if (!quiet)
fprintf(realstdout, "%s\n", filename.buf + outdir_offset);
 
-   if (freopen(filename.buf, "w", stdout) == NULL)
+   if ((rev->diffopt.file = fopen(filename.buf, "w")) == NULL)
return error(_("Cannot open patch file %s"), filename.buf);
 
strbuf_release();
@@ -882,15 +883,15 @@ static void

[PATCH v2 5/7] format-patch: explicitly switch off color when writing to files

2016-06-20 Thread Johannes Schindelin 
We rely on the auto-detection ("is stdout a terminal?") to determine
whether to use color in the output of format-patch or not. That happens
to work because we freopen() stdout when redirecting the output to files.

However, we are about to fix that work-around, in which case the
auto-detection has no chance to guess whether to use color or not.

But then, we do not need to guess to begin with. We know that we do not
want to use ANSI color sequences in the output files. So let's just be
explicit about our wishes.

Signed-off-by: Johannes Schindelin 
---
 builtin/log.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/builtin/log.c b/builtin/log.c
index 099f4f7..abd889b 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1569,6 +1569,7 @@ int cmd_format_patch(int argc, const char **argv, const 
char *prefix)
setup_pager();
 
if (output_directory) {
+   rev.diffopt.use_color = 0;
if (use_stdout)
die(_("standard output, or directory, which one?"));
if (mkdir(output_directory, 0777) < 0 && errno != EEXIST)
-- 
2.9.0.119.g370c5a9


--
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 7/7] format-patch: use stdout directly

2016-06-20 Thread Johannes Schindelin 
Earlier, we freopen()ed stdout in order to write patches to files.
That forced us to duplicate stdout (naming it "realstdout") because we
*still* wanted to be able to report the file names.

As we do not abuse stdout that way anymore, we no longer need to
duplicate stdout, either.

Signed-off-by: Johannes Schindelin 
---
 builtin/log.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/builtin/log.c b/builtin/log.c
index db034a8..5a889d5 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -796,7 +796,6 @@ static int git_format_config(const char *var, const char 
*value, void *cb)
return git_log_config(var, value, cb);
 }
 
-static FILE *realstdout = NULL;
 static const char *output_directory = NULL;
 static int outdir_offset;
 
@@ -822,7 +821,7 @@ static int open_next_file(struct commit *commit, const char 
*subject,
fmt_output_subject(, subject, rev);
 
if (!quiet)
-   fprintf(realstdout, "%s\n", filename.buf + outdir_offset);
+   printf("%s\n", filename.buf + outdir_offset);
 
if ((rev->diffopt.file = fopen(filename.buf, "w")) == NULL)
return error(_("Cannot open patch file %s"), filename.buf);
@@ -1629,9 +1628,6 @@ int cmd_format_patch(int argc, const char **argv, const 
char *prefix)
get_patch_ids(, );
}
 
-   if (!use_stdout)
-   realstdout = xfdopen(xdup(1), "w");
-
if (prepare_revision_walk())
die(_("revision walk setup failed"));
rev.boundary = 1;
-- 
2.9.0.119.g370c5a9
--
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/7] shortlog: support outputting to streams other than stdout

2016-06-20 Thread Johannes Schindelin 
This will be needed to avoid freopen() in `git format-patch`.

Signed-off-by: Johannes Schindelin 
---
 builtin/shortlog.c | 13 -
 shortlog.h |  1 +
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index bfc082e..4c68ba7 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -229,6 +229,7 @@ void shortlog_init(struct shortlog *log)
log->wrap = DEFAULT_WRAPLEN;
log->in1 = DEFAULT_INDENT1;
log->in2 = DEFAULT_INDENT2;
+   log->file = stdout;
 }
 
 int cmd_shortlog(int argc, const char **argv, const char *prefix)
@@ -310,22 +311,24 @@ void shortlog_output(struct shortlog *log)
for (i = 0; i < log->list.nr; i++) {
const struct string_list_item *item = >list.items[i];
if (log->summary) {
-   printf("%6d\t%s\n", (int)UTIL_TO_INT(item), 
item->string);
+   fprintf(log->file, "%6d\t%s\n",
+   (int)UTIL_TO_INT(item), item->string);
} else {
struct string_list *onelines = item->util;
-   printf("%s (%d):\n", item->string, onelines->nr);
+   fprintf(log->file, "%s (%d):\n",
+   item->string, onelines->nr);
for (j = onelines->nr - 1; j >= 0; j--) {
const char *msg = onelines->items[j].string;
 
if (log->wrap_lines) {
strbuf_reset();
add_wrapped_shortlog_msg(, msg, log);
-   fwrite(sb.buf, sb.len, 1, stdout);
+   fwrite(sb.buf, sb.len, 1, log->file);
}
else
-   printf("  %s\n", msg);
+   fprintf(log->file, "  %s\n", msg);
}
-   putchar('\n');
+   fputc('\n', log->file);
onelines->strdup_strings = 1;
string_list_clear(onelines, 0);
free(onelines);
diff --git a/shortlog.h b/shortlog.h
index de4f86f..5a326c6 100644
--- a/shortlog.h
+++ b/shortlog.h
@@ -17,6 +17,7 @@ struct shortlog {
char *common_repo_prefix;
int email;
struct string_list mailmap;
+   FILE *file;
 };
 
 void shortlog_init(struct shortlog *log);
-- 
2.9.0.119.g370c5a9


--
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/7] log-tree: respect diffopt's configured output file stream

2016-06-20 Thread Johannes Schindelin 
The diff options already know how to print the output anywhere else
than stdout. The same is needed for log output in general, e.g.
when writing patches to files in `git format-patch`. Let's allow
users to use log_tree_commit() *without* changing global state via
freopen().

Signed-off-by: Johannes Schindelin 
---
 log-tree.c | 65 +++---
 1 file changed, 33 insertions(+), 32 deletions(-)

diff --git a/log-tree.c b/log-tree.c
index 78a5381..968428a 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -159,12 +159,12 @@ void load_ref_decorations(int flags)
}
 }
 
-static void show_parents(struct commit *commit, int abbrev)
+static void show_parents(struct commit *commit, int abbrev, FILE *file)
 {
struct commit_list *p;
for (p = commit->parents; p ; p = p->next) {
struct commit *parent = p->item;
-   printf(" %s", find_unique_abbrev(parent->object.oid.hash, 
abbrev));
+   fprintf(file, " %s", 
find_unique_abbrev(parent->object.oid.hash, abbrev));
}
 }
 
@@ -172,7 +172,7 @@ static void show_children(struct rev_info *opt, struct 
commit *commit, int abbre
 {
struct commit_list *p = lookup_decoration(>children, 
>object);
for ( ; p; p = p->next) {
-   printf(" %s", find_unique_abbrev(p->item->object.oid.hash, 
abbrev));
+   fprintf(opt->diffopt.file, " %s", 
find_unique_abbrev(p->item->object.oid.hash, abbrev));
}
 }
 
@@ -286,11 +286,11 @@ void show_decorations(struct rev_info *opt, struct commit 
*commit)
struct strbuf sb = STRBUF_INIT;
 
if (opt->show_source && commit->util)
-   printf("\t%s", (char *) commit->util);
+   fprintf(opt->diffopt.file, "\t%s", (char *) commit->util);
if (!opt->show_decorations)
return;
format_decorations(, commit, opt->diffopt.use_color);
-   fputs(sb.buf, stdout);
+   fputs(sb.buf, opt->diffopt.file);
strbuf_release();
 }
 
@@ -364,18 +364,18 @@ void log_write_email_headers(struct rev_info *opt, struct 
commit *commit,
subject = "Subject: ";
}
 
-   printf("From %s Mon Sep 17 00:00:00 2001\n", name);
+   fprintf(opt->diffopt.file, "From %s Mon Sep 17 00:00:00 2001\n", name);
graph_show_oneline(opt->graph);
if (opt->message_id) {
-   printf("Message-Id: <%s>\n", opt->message_id);
+   fprintf(opt->diffopt.file, "Message-Id: <%s>\n", 
opt->message_id);
graph_show_oneline(opt->graph);
}
if (opt->ref_message_ids && opt->ref_message_ids->nr > 0) {
int i, n;
n = opt->ref_message_ids->nr;
-   printf("In-Reply-To: <%s>\n", 
opt->ref_message_ids->items[n-1].string);
+   fprintf(opt->diffopt.file, "In-Reply-To: <%s>\n", 
opt->ref_message_ids->items[n-1].string);
for (i = 0; i < n; i++)
-   printf("%s<%s>\n", (i > 0 ? "\t" : "References: "),
+   fprintf(opt->diffopt.file, "%s<%s>\n", (i > 0 ? "\t" : 
"References: "),
   opt->ref_message_ids->items[i].string);
graph_show_oneline(opt->graph);
}
@@ -432,7 +432,7 @@ static void show_sig_lines(struct rev_info *opt, int 
status, const char *bol)
reset = diff_get_color_opt(>diffopt, DIFF_RESET);
while (*bol) {
eol = strchrnul(bol, '\n');
-   printf("%s%.*s%s%s", color, (int)(eol - bol), bol, reset,
+   fprintf(opt->diffopt.file, "%s%.*s%s%s", color, (int)(eol - 
bol), bol, reset,
   *eol ? "\n" : "");
graph_show_oneline(opt->graph);
bol = (*eol) ? (eol + 1) : eol;
@@ -553,17 +553,17 @@ void show_log(struct rev_info *opt)
 
if (!opt->graph)
put_revision_mark(opt, commit);
-   fputs(find_unique_abbrev(commit->object.oid.hash, 
abbrev_commit), stdout);
+   fputs(find_unique_abbrev(commit->object.oid.hash, 
abbrev_commit), opt->diffopt.file);
if (opt->print_parents)
-   show_parents(commit, abbrev_commit);
+   show_parents(commit, abbrev_commit, opt->diffopt.file);
if (opt->children.name)
show_children(opt, commit, abbrev_commit);
show_decorations(opt, commit);
if (opt->graph && !graph_is_commit_finished(opt->graph)) {
-   putchar('\n');
+   fputc('\n', opt->diffopt.file);
graph_show_remainder(opt->graph);
}
-   putchar(opt->diffopt.line_termination);
+   fputc(opt->diffopt.line_termination, opt->diffopt.file);
return;
}
 
@@ -589,7 +589,7 @@ void show_log(struct rev_info *opt)

[PATCH v2 3/7] graph: respect the diffopt.file setting

2016-06-20 Thread Johannes Schindelin 
When the caller overrides diffopt.file (which defaults to stdout),
the diff machinery already redirects its output, and the graph display
should also write to that file.

Signed-off-by: Johannes Schindelin 
---
 graph.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/graph.c b/graph.c
index 1350bdd..8ae56bc 100644
--- a/graph.c
+++ b/graph.c
@@ -17,8 +17,8 @@
 static void graph_padding_line(struct git_graph *graph, struct strbuf *sb);
 
 /*
- * Print a strbuf to stdout.  If the graph is non-NULL, all lines but the
- * first will be prefixed with the graph output.
+ * Print a strbuf.  If the graph is non-NULL, all lines but the first will be
+ * prefixed with the graph output.
  *
  * If the strbuf ends with a newline, the output will end after this
  * newline.  A new graph line will not be printed after the final newline.
@@ -1193,9 +1193,10 @@ void graph_show_commit(struct git_graph *graph)
 
while (!shown_commit_line && !graph_is_commit_finished(graph)) {
shown_commit_line = graph_next_line(graph, );
-   fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
+   fwrite(msgbuf.buf, sizeof(char), msgbuf.len,
+   graph->revs->diffopt.file);
if (!shown_commit_line)
-   putchar('\n');
+   fputc('\n', graph->revs->diffopt.file);
strbuf_setlen(, 0);
}
 
@@ -1210,7 +1211,7 @@ void graph_show_oneline(struct git_graph *graph)
return;
 
graph_next_line(graph, );
-   fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
+   fwrite(msgbuf.buf, sizeof(char), msgbuf.len, graph->revs->diffopt.file);
strbuf_release();
 }
 
@@ -1222,7 +1223,7 @@ void graph_show_padding(struct git_graph *graph)
return;
 
graph_padding_line(graph, );
-   fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
+   fwrite(msgbuf.buf, sizeof(char), msgbuf.len, graph->revs->diffopt.file);
strbuf_release();
 }
 
@@ -1239,12 +1240,13 @@ int graph_show_remainder(struct git_graph *graph)
 
for (;;) {
graph_next_line(graph, );
-   fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
+   fwrite(msgbuf.buf, sizeof(char), msgbuf.len,
+   graph->revs->diffopt.file);
strbuf_setlen(, 0);
shown = 1;
 
if (!graph_is_commit_finished(graph))
-   putchar('\n');
+   fputc('\n', graph->revs->diffopt.file);
else
break;
}
@@ -1259,7 +1261,8 @@ static void graph_show_strbuf(struct git_graph *graph, 
struct strbuf const *sb)
char *p;
 
if (!graph) {
-   fwrite(sb->buf, sizeof(char), sb->len, stdout);
+   fwrite(sb->buf, sizeof(char), sb->len,
+   graph->revs->diffopt.file);
return;
}
 
@@ -1277,7 +1280,7 @@ static void graph_show_strbuf(struct git_graph *graph, 
struct strbuf const *sb)
} else {
len = (sb->buf + sb->len) - p;
}
-   fwrite(p, sizeof(char), len, stdout);
+   fwrite(p, sizeof(char), len, graph->revs->diffopt.file);
if (next_p && *next_p != '\0')
graph_show_oneline(graph);
p = next_p;
@@ -1297,7 +1300,8 @@ void graph_show_commit_msg(struct git_graph *graph,
 * CMIT_FMT_USERFORMAT are already missing a terminating
 * newline.  All of the other formats should have it.
 */
-   fwrite(sb->buf, sizeof(char), sb->len, stdout);
+   fwrite(sb->buf, sizeof(char), sb->len,
+   graph->revs->diffopt.file);
return;
}
 
@@ -1318,7 +1322,7 @@ void graph_show_commit_msg(struct git_graph *graph,
 * new line.
 */
if (!newline_terminated)
-   putchar('\n');
+   fputc('\n', graph->revs->diffopt.file);
 
graph_show_remainder(graph);
 
@@ -1326,6 +1330,6 @@ void graph_show_commit_msg(struct git_graph *graph,
 * If sb ends with a newline, our output should too.
 */
if (newline_terminated)
-   putchar('\n');
+   fputc('\n', graph->revs->diffopt.file);
}
 }
-- 
2.9.0.119.g370c5a9


--
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/7] Let log-tree and friends respect diffopt's `file` field

2016-06-20 Thread Johannes Schindelin 
The idea is to allow callers to redirect log-tree's output to a file
without having to freopen() stdout (which would modify global state,
a big no-no-no for library functions).

I reviewed log-tree.c, graph.c, line-log.c, builtin/shortlog.c and
builtin/log.c line by line to ensure that all calls that assumed stdout
previously now use the `file` field instead, of course. I would
welcome additional eyes to go over the code to confirm that I did not
miss anything.

This patch series ends up removing the freopen() call in the
format-patch command, but that is only a by-product. The ulterior motive
behind this series is to allow the sequencer to write a `patch` file as
part of my endeavor to move large chunks of rebase -i into a builtin.

Speaking of said endeavor: it is going a lot slower than I would like,
but I really need rebase -i to be robust. To that end, I not only review
and re-review my patches frequently, I also use a cross-validation
technique inspired by my original ll-merge validation as well as
GitHub's Scientist library: I taught rebase -i to run every interactive
rebase twice, once with the original shell script's code, and once with
the builtin rebase--helper, and then to verify that the end result is as
similar as can be expected (the commit dates will differ most of the
time, of course).

It is a bit tedious, of course, because I have to resolve every merge
conflict twice, I have to reword everything twice (identically!), and I
have to wait longer for the rebase to finish. It is worth it, though,
because I really need rebase -i to be robust, as it is the center piece
of almost all of my workflows.

I organized the patch series into a thicket of branches, to make it
easier to review them; In addition to this here patch series, I plan to
submit 11 separate, partially interdependent series, resubmit another
one, and I already submitted a couple of patches earlier that were
integrated or replaced by superior solutions (thanks, Peff!). Skipping
the temporary patches (e.g. for cross-validation), that leaves me with
99 patches to submit in total (sing with me: "99 patches of code to
submit, 99 patches of code, ...").

I was curious just how much these patches could accelerate rebase -i, so
I disabled the cross-validation temprarily and let Travis measure the
performance improvements via the t/perf test that was already merged to
`master`. Look for "3404.2" in this build's logs:
https://travis-ci.org/git/git/builds/13824

It looks like a 3x speedup on Linux, a 4x speedup on MacOSX and my local
measurements suggest a >5x speed-up on Windows.


Johannes Schindelin (7):
  log-tree: respect diffopt's configured output file stream
  line-log: respect diffopt's configured output file stream
  graph: respect the diffopt.file setting
  shortlog: support outputting to streams other than stdout
  format-patch: explicitly switch off color when writing to files
  format-patch: avoid freopen()
  format-patch: use stdout directly

 builtin/log.c  | 71 +++---
 builtin/shortlog.c | 13 ++
 graph.c| 30 +--
 line-log.c | 34 +-
 log-tree.c | 65 +
 shortlog.h |  1 +
 6 files changed, 111 insertions(+), 103 deletions(-)

Published-As: https://github.com/dscho/git/releases/tag/diffopt.file-v2
-- 
2.9.0.119.g370c5a9

base-commit: 05219a1276341e72d8082d76b7f5ed394b7437a4
--
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/7] line-log: respect diffopt's configured output file stream

2016-06-20 Thread Johannes Schindelin 
The diff machinery can optionally output to a file stream other than
stdout, by overriding diffopt.file. In such a case, the rest of the
log tree machinery should also write to that stream.

Currently, there is no user of the line level log that wants to
redirect output to a file. Therefore, one might argue that it is
superfluous to support that now. However, it is better to be
consistent now, rather than to face hard-to-debug problems later.

Signed-off-by: Johannes Schindelin 
---
 line-log.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/line-log.c b/line-log.c
index bbe31ed..c3b8563 100644
--- a/line-log.c
+++ b/line-log.c
@@ -841,7 +841,7 @@ static char *get_nth_line(long line, unsigned long *ends, 
void *data)
 
 static void print_line(const char *prefix, char first,
   long line, unsigned long *ends, void *data,
-  const char *color, const char *reset)
+  const char *color, const char *reset, FILE *file)
 {
char *begin = get_nth_line(line, ends, data);
char *end = get_nth_line(line+1, ends, data);
@@ -852,14 +852,14 @@ static void print_line(const char *prefix, char first,
had_nl = 1;
}
 
-   fputs(prefix, stdout);
-   fputs(color, stdout);
-   putchar(first);
-   fwrite(begin, 1, end-begin, stdout);
-   fputs(reset, stdout);
-   putchar('\n');
+   fputs(prefix, file);
+   fputs(color, file);
+   fputc(first, file);
+   fwrite(begin, 1, end-begin, file);
+   fputs(reset, file);
+   fputc('\n', file);
if (!had_nl)
-   fputs("\\ No newline at end of file\n", stdout);
+   fputs("\\ No newline at end of file\n", file);
 }
 
 static char *output_prefix(struct diff_options *opt)
@@ -898,12 +898,12 @@ static void dump_diff_hacky_one(struct rev_info *rev, 
struct line_log_data *rang
fill_line_ends(pair->one, _lines, _ends);
fill_line_ends(pair->two, _lines, _ends);
 
-   printf("%s%sdiff --git a/%s b/%s%s\n", prefix, c_meta, pair->one->path, 
pair->two->path, c_reset);
-   printf("%s%s--- %s%s%s\n", prefix, c_meta,
+   fprintf(opt->file, "%s%sdiff --git a/%s b/%s%s\n", prefix, c_meta, 
pair->one->path, pair->two->path, c_reset);
+   fprintf(opt->file, "%s%s--- %s%s%s\n", prefix, c_meta,
   pair->one->sha1_valid ? "a/" : "",
   pair->one->sha1_valid ? pair->one->path : "/dev/null",
   c_reset);
-   printf("%s%s+++ b/%s%s\n", prefix, c_meta, pair->two->path, c_reset);
+   fprintf(opt->file, "%s%s+++ b/%s%s\n", prefix, c_meta, pair->two->path, 
c_reset);
for (i = 0; i < range->ranges.nr; i++) {
long p_start, p_end;
long t_start = range->ranges.ranges[i].start;
@@ -945,7 +945,7 @@ static void dump_diff_hacky_one(struct rev_info *rev, 
struct line_log_data *rang
}
 
/* Now output a diff hunk for this range */
-   printf("%s%s@@ -%ld,%ld +%ld,%ld @@%s\n",
+   fprintf(opt->file, "%s%s@@ -%ld,%ld +%ld,%ld @@%s\n",
   prefix, c_frag,
   p_start+1, p_end-p_start, t_start+1, t_end-t_start,
   c_reset);
@@ -953,18 +953,18 @@ static void dump_diff_hacky_one(struct rev_info *rev, 
struct line_log_data *rang
int k;
for (; t_cur < diff->target.ranges[j].start; t_cur++)
print_line(prefix, ' ', t_cur, t_ends, 
pair->two->data,
-  c_context, c_reset);
+  c_context, c_reset, opt->file);
for (k = diff->parent.ranges[j].start; k < 
diff->parent.ranges[j].end; k++)
print_line(prefix, '-', k, p_ends, 
pair->one->data,
-  c_old, c_reset);
+  c_old, c_reset, opt->file);
for (; t_cur < diff->target.ranges[j].end && t_cur < 
t_end; t_cur++)
print_line(prefix, '+', t_cur, t_ends, 
pair->two->data,
-  c_new, c_reset);
+  c_new, c_reset, opt->file);
j++;
}
for (; t_cur < t_end; t_cur++)
print_line(prefix, ' ', t_cur, t_ends, pair->two->data,
-  c_context, c_reset);
+  c_context, c_reset, opt->file);
}
 
free(p_ends);
@@ -977,7 +977,7 @@ static void dump_diff_hacky_one(struct rev_info *rev, 
struct line_log_data *rang
  */
 static void dump_diff_hacky(struct rev_info *rev, struct line_log_data *range)
 {
-   puts(output_prefix(>diffopt));
+

Re: [PATCH v2 0/8] object_id part 4

2016-06-20 Thread Jeff King 
On Mon, Jun 20, 2016 at 09:01:30AM +0200, Johannes Schindelin wrote:

> On Sun, 19 Jun 2016, Jeff King wrote:
> 
> > I think traditionally we've avoided struct assignment because some
> > ancient compilers didn't do it. But it's in C89, and I suspect it's
> > crept into the code base anyway over the years without anyone
> > complaining.
> 
> I fear that's my fault, at least partially, seeing as merge-recursive.c
> even *returns* structs (see 6d297f81; I plan to fix that as part of the
> cleaned-up am-3-merge-recursive-direct patch series).

Heh, that commit is quite old. If nobody has complained about it, then I
think there is nothing to be sorry about. If struct assignment (and
returns) work everywhere, and they make the code easier to read, we
should be using them.

I am on the fence regarding oidcpy/oidclr. I agree they _could_ be
struct assignments, but it is also convenient to have concept wrapped up
in a function, in case we ever want to do anything more complicated.

-Peff
--
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 5/5] format-patch: avoid freopen()

2016-06-20 Thread Johannes Schindelin 
Hi Eric,

On Mon, 20 Jun 2016, Eric Sunshine wrote:

> On Mon, Jun 20, 2016 at 2:26 AM, Johannes Schindelin
>  wrote:
> > On Sun, 19 Jun 2016, Eric Sunshine wrote:
> >> On Sat, Jun 18, 2016 at 6:04 AM, Johannes Schindelin
> >>  wrote:
> >> > if (output_directory) {
> >> > +   rev.diffopt.use_color = 0;
> >>
> >> What is this change about? It doesn't seem to be related to anything
> >> else in the patch.
> >
> > Good point, I completely forgot to mention this is the commit message.
> >
> > When format-patch calls the diff machinery, want_color() is used to
> > determine whether to use ANSI color sequences or not. If use_color is not
> > set explicitly, isatty(1) is used to determine whether or not the user
> > wants color. When stdout was freopen()ed, this isatty(1) call naturally
> > looked at the file descriptor that was reopened, and determined correctly
> > that no color was desired.
> >
> > With the freopen() call gone, stdout may very well be the terminal. But we
> > still do not want color because the output is intended to go to a file (at
> > least if output_directory is set).
> 
> Would it make sense to do this as a separate preparatory patch, or is
> it just too minor?

That's a good point. It *is* a change in its own right. Will reroll.

Thanks,
Dscho
--
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] git 2.9.0 clone --recursive fails on cloning a submodule

2016-06-20 Thread Jeff King 
On Sun, Jun 19, 2016 at 06:09:28PM -0700, Stefan Beller wrote:

> > I hadn't paid much attention to this topic originally, but was surprised
> > that "--depth 10" in the clone implies "--depth 1" in the submodule.
> > This is not really related to your patch (in fact, your patch makes the
> > logic go away). But maybe something to consider if it's ever resurrected
> > (or possibly if somebody runs "--shallow-submodules --depth 5" we should
> > pass --depth=1; I dunno).
> 
> How often do we see a depth != 1 in practice?
> I have the impression (and no data to back up my claim) that a binary
> switch for nonshallow or depth 1 would serve us just as good, which is why
> I did not want to ad complexity to the submodule depth.
> (What if you want submodule A with depth 2 and B with 5? In that
> case get them all shallow and deepen as appropriate, would be my answer)

To be honest, I don't know why people use anything except --depth=1, but
it's clear from my experience that they do. This example has --depth=10,
and on the server side at GitHub I have seen similar numbers from clients,
especially CI services.

(I take special note of such cases because --shallow quite often causes
performance problems on the server side, though generally --depth=10 is
not any worse than --depth=1. The worst case is really
"--no-single-branch --depth=1", which wants a ton of objects but has to
throw away all of the on-disk deltas).

> > We are not really testing "does not imply" here, but "passing
> > --shallow-submodules works". The "does not imply" test would be cloning
> > without the option and checking that the resulting submodules are not
> > shallow.
> 
> In case we want to be sure that it works for 2.9.1, i.e. we treat it
> as a regression,
> we need to test the "does not imply" a bit more I would think. I can send that
> test on top tomorrow if you'd like to.

I think it's worth doing (and testing both: the default behavior, and
that the --shallow-submodules feature works). Thanks.

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

2016-06-20 Thread 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

2016-06-20 Thread 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

2016-06-20 Thread 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: What's cooking in git.git (Jun 2016, #05; Thu, 16)

2016-06-20 Thread Lars Schneider 

> On 20 Jun 2016, at 01:51, Junio C Hamano  wrote:
> 
> Junio C Hamano  writes:
> 
>> Michael Haggerty  writes:
>> 
>>> According to [1], something in that test seems to have been trying to run
>>> 
>>>git update-ref -d git-p4-tmp/6
>>> 
>>> Similarly in the other failed test.
>> 
>> Ah, OK, that would try mucking with .git/git-p4-tmp/6 but that is
>> not a place to have a ref.  It will not participate in reachability
>> analysis and will end up losing the referents.
>> 
>> Perhaps placing it under refs/git-p4-tmp would fix it (both in
>> git-p4 and in tests)?
> 
> Oh, another thing.  If these refs are meant to be transient, they
> are likely to be per worktree, if "git worktree" managed multiple
> worktrees that share the same set of branches and tags are in use.
> 
> I recall we carved out one hierarchy under refs/ as "not shared
> across worktrees" (was that refs/worktree/ hierarchy?  I didn't
> check but please do so when the patch actually is written), and
> that hierarchy is the appropriate thing to use for this, I think.

Thanks for the hint. It looks like as if the "per worktree" decision
is made in "ref.c:466" "is_per_worktree_ref":
https://github.com/git/git/blob/3dc84b0c19932ec9947ca4936b6bfd6421ccb1b4/refs.c#L466-L470

In ce414b3 "refs/bisect" was added to a list of prefixes that are
per worktree. I could easily add "refs/git-p4-tmp" to this list but
I don't think that would be a good solution. I would prefer to go with 
your suggestion and add "refs/worktree" to the prefix list and then use
"refs/worktree/git-p4-tmp".

Later on we could move "refs/bisect" to "refs/worktree/bisect" and
simplify the "is_per_worktree_ref" code, too.

Thoughts?

Thanks,
Lars--
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

[GSOC Update] Week 7

2016-06-20 Thread Pranit Bauva 
= SUMMARY ==
My public git.git is available here[1]. I regularly keep pushing my work so
anyone interested can track me there. Feel free to participate in the
discussions going on PRs with my mentors. Your comments are valuable.


=== INTRODUCTION  ==
The purpose of this project is to convert the git-bisect utility which partly
exists in the form of shell scripts to C code so as to make it more portable.
I plan to do this by converting each function to C and then calling it from
git-bisect.sh so as to use the existing test suite to test the function which
is converted.

Mentors:
Christian Couder 
Lars Schneider 


== Updates =
Things which were done in this week:

 * I have converted check_and_set_terms() and have also sent an RFC[2] to the
   mailing list for discussion which hasn't yet collected any comments. It is
   kind of important to discuss this as it uses a way to set the global
   variables in the script by writing it to a file and then reading it.

 * I have also converted bisect_next_check() but this has a bug which will
   soon be fixed. This is available here[3].

 * I have converted get_terms().

 * I am on my way to convert bisect_terms() which should probably finish by
   tomorrow.

 * I also send out a patch[4] which describes the return value of
   strbuf_read_file() and is queued on the pu branch.

= NEXT STEPS 
Things which would be done in the coming week:

 * Finish off bisect_terms().

 * bisect_run().

 * bisect_replay().

 * I have my mid term evaluations this week. Hope I clear it successfully.

[1]: https://github.com/pranitbauva1997/git
[2]: http://thread.gmane.org/gmane.comp.version-control.git/297520
[3]: https://github.com/pranitbauva1997/git/pull/17
[4]: http://thread.gmane.org/gmane.comp.version-control.git/297266

Regards,
Pranit Bauva
--
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

may be bug in svn fetch no-follow-parent

2016-06-20 Thread Александр Овчинников 
Why git svn fetch try to handle mergeinfo changes when no-follow-parent is 
enabled?
Git try to follow parents regardless of this option value.
If branch created without this option then git will follow parent succesfully
If branch created with this option then git try to follow and fail with "cannot 
find common ancestor" error
If branch does not exists (ignored) then git try to follow and fail with 
"couldn't find revmap" error. It is very long operation
--
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/8] object_id part 4

2016-06-20 Thread Johannes Schindelin 
Hi Peff,

On Sun, 19 Jun 2016, Jeff King wrote:

> I think traditionally we've avoided struct assignment because some
> ancient compilers didn't do it. But it's in C89, and I suspect it's
> crept into the code base anyway over the years without anyone
> complaining.

I fear that's my fault, at least partially, seeing as merge-recursive.c
even *returns* structs (see 6d297f81; I plan to fix that as part of the
cleaned-up am-3-merge-recursive-direct patch series).

Sorry,
Dscho
--
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] perf: accommodate for MacOSX

2016-06-20 Thread Johannes Schindelin 
Hi Lars,

On Sun, 19 Jun 2016, Lars Schneider wrote:

> > On 18 Jun 2016, at 15:03, Johannes Schindelin
> >  wrote:
> > 
> > As this developer has no access to MacOSX developer setups anymore,
> > Travis becomes the best bet to run performance tests on that OS.
>
> We don't run the performance tests on Travis CI right now.
> Maybe we should? With your patch below it should work, right?

It *should* work, but I'd be reluctant to run them as part of the CI: we
have no real chance to catch perf regressions as of now. So all it would
do would be to add load to Travis.

> I only saw one error on my local OS X machine here:
> https://github.com/git/git/blob/05219a1276341e72d8082d76b7f5ed394b7437a4/t/perf/p-perf-lib-sanity.sh#L26

Yeah, well, I should have been clearer in my commit message: this patch
allows the perf tests to *run*, not to *pass*... ;-)

> Does the export of foo not work properly on OS X? "$foo" is empty...

Sorry, as I said: I no longer have access to a dev setup running MacOSX.

Ciao,
Dscho

P.S.: Please save me time by deleting the remainder of the quoted mail
when it is irrelevant to your reply. 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: [PATCH 5/5] format-patch: avoid freopen()

2016-06-20 Thread Eric Sunshine 
On Mon, Jun 20, 2016 at 2:26 AM, Johannes Schindelin
 wrote:
> On Sun, 19 Jun 2016, Eric Sunshine wrote:
>> On Sat, Jun 18, 2016 at 6:04 AM, Johannes Schindelin
>>  wrote:
>> > if (output_directory) {
>> > +   rev.diffopt.use_color = 0;
>>
>> What is this change about? It doesn't seem to be related to anything
>> else in the patch.
>
> Good point, I completely forgot to mention this is the commit message.
>
> When format-patch calls the diff machinery, want_color() is used to
> determine whether to use ANSI color sequences or not. If use_color is not
> set explicitly, isatty(1) is used to determine whether or not the user
> wants color. When stdout was freopen()ed, this isatty(1) call naturally
> looked at the file descriptor that was reopened, and determined correctly
> that no color was desired.
>
> With the freopen() call gone, stdout may very well be the terminal. But we
> still do not want color because the output is intended to go to a file (at
> least if output_directory is set).

Would it make sense to do this as a separate preparatory patch, or is
it just too minor?

> So how about this commit message (I inserted the "Note: ..." paragraph)?
>
> -- snipsnap --
> format-patch: avoid freopen()
> [...]
> Note: we now have to set use_color = 0 explicitly when writing to files,
> as the auto-detection whether to colorify the output *still* looks at
> stdout (which is no longer freopen()ed, and therefore might still be
> printing to the terminal).

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: [PATCH 5/5] format-patch: avoid freopen()

2016-06-20 Thread Johannes Schindelin 
Hi Eric,

On Sun, 19 Jun 2016, Eric Sunshine wrote:

> On Sat, Jun 18, 2016 at 6:04 AM, Johannes Schindelin
>  wrote:
> > We just taught the relevant functions to respect the diffopt.file field,
> > to allow writing somewhere else than stdout. Let's make use of it.
> > [...]
> > Signed-off-by: Johannes Schindelin 
> > ---
> > diff --git a/builtin/log.c b/builtin/log.c
> > @@ -1569,6 +1570,7 @@ int cmd_format_patch(int argc, const char **argv, 
> > const char *prefix)
> > setup_pager();
> >
> > if (output_directory) {
> > +   rev.diffopt.use_color = 0;
> 
> What is this change about? It doesn't seem to be related to anything
> else in the patch.

Good point, I completely forgot to mention this is the commit message.

When format-patch calls the diff machinery, want_color() is used to
determine whether to use ANSI color sequences or not. If use_color is not
set explicitly, isatty(1) is used to determine whether or not the user
wants color. When stdout was freopen()ed, this isatty(1) call naturally
looked at the file descriptor that was reopened, and determined correctly
that no color was desired.

With the freopen() call gone, stdout may very well be the terminal. But we
still do not want color because the output is intended to go to a file (at
least if output_directory is set).

So how about this commit message (I inserted the "Note: ..." paragraph)?

-- snipsnap --
format-patch: avoid freopen()

We just taught the relevant functions to respect the diffopt.file field,
to allow writing somewhere else than stdout. Let's make use of it.

Technically, we do not need to avoid that call in a builtin: we assume
that builtins (as opposed to library functions) are stand-alone programs
that may do with their (global) state. Yet, we want to be able to reuse
that code in properly lib-ified code, e.g. when converting scripts into
builtins.

Note: we now have to set use_color = 0 explicitly when writing to files,
as the auto-detection whether to colorify the output *still* looks at
stdout (which is no longer freopen()ed, and therefore might still be
printing to the terminal).

Further, while we did not *have* to touch the cmd_show() and cmd_cherry()
code paths (because they do not want to write anywhere but stdout as of
yet), it just makes sense to be consistent, making it easier and safer to
move the code later.

Signed-off-by: Johannes Schindelin 

--
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: What's cooking in git.git (Jun 2016, #05; Thu, 16)

2016-06-20 Thread Torsten Bögershausen 


There is a conflict in pu:
"jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"

(And currently pu didn't compile)

(I will hopefully be able to do a separate review of the smudge/clean patch)

(And jo...@joeyh.name is not reachable from web.de)

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