Re: Git p4 sync changelist interval
On 6 June 2017 at 00:29, Luke Diamand wrote: > On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote: >> 2017-06-04 14:09 GMT+03:00 Luke Diamand : >>> >>> >>> > >>> > The problem, as I see it, is that before syncing changes in the given >>> > range, p4 task does not sync to cl1 version of the repo, and applies >>> > commits to the empty repository. >>> > Is it a bug or my misunderstanding of how git p4 should work? >>> >>> Possibly I'm misunderstanding what you're doing! Can you give a >>> sequence of steps to show the problem? >> >> What I meant is: >> >> 1. Create p4 depot >> 2. Add first.file (CL 2) >> 3. Add second.file (at CL 3) >> 4. Add third.file (at CL 4) >> 5. Modify first.file (at CL 5) >> 4. git-p4 clone //depot@3,5 >> >> In this case first.file, will not be represented in the repository. > > Hmmm, it's not working right for me. Although in my case I seem to be > missing the second file. > > It's fine if I don't use the revision range "3,5". It's also fine if I do: git p4 sync //depot@3 cd depot git p4 rebase
Re: Git "Keeping Original Dates"
On Mon, Jun 05, 2017 at 05:14:01PM -0400, Hector Santos wrote: > I'm implementing GIT. If there an option or compile/version that "keep" > file timestamps? Just in case you've missed it, there's an explanation of why Git behaves the way it does in this regard [1]. 1. https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F
Re: [PATCH/RFC v4 3/3] branch: add copy branch feature implementation
On Tue, Jun 6, 2017 at 2:10 AM, Junio C Hamano wrote:
> Sahil Dua writes:
>
>> I want suggestions about one logical point raised by Evar.
>>
>> Let's consider a case that I'm on branch maint and then I do 'git
>> checkout master' followed by 'git branch -m feature', it will rename
>> master branch to feature. Now if I do 'git checkout -' to go to the
>> last branch, it will take me to maint since master branch doesn't
>> exist in this case.
>>
>> Now, for this copy operation - if I'm on branch maint and then I do
>> 'git checkout master' followed by 'git branch -c feature', it will
>> copy master branch to feature. Now if I do 'git checkout -' to go to
>> the last branch, it will again go to maint (according to the current
>> implementation). What do you think it should do? Is this the desired
>> behavior? Or should it go to master branch since that was the branch
>> checked out before copying.
>>
>> Also, in case this needs to be changed, can someone please point me to
>> how it's being handled so that I can change the behavior.
>
> When somebody says "I want to rename my current branch to X", it is
> clear that the person wants to end up being on a branch called X.
>
> To me, "I want to copy my current branch to Y" sounds more like "I
> want to create another Y that looks just like the current branch,
> but I want stay on my current branch".
This would be more useful to me if the semantics were copy & checkout
instead of just copy, since when I'd like to copy branches it's almost
always because I'm on some topic branch and want to create & work on a
new copy of that topic branch.
It would also be consistent with "git branch -m" and easier to
explain, i.e. "git branch -c just like -m except it doesn't delete the
branch name/config you moved away from".
Like with -m, you can still move around random other branches, e.g.:
# While on master
$ git branch -m some-other new-some-other
This will just move some-other to new-some-other without checkout out
new-some-other, it's only when the source name is the same as your
currently checked out branch that you checkout a new branch,
Now, of course the difference is that when you -m your current branch
it doesn't really have a choice of whether to move your checkout as
well (although I suppose it could leave you in a detached HEAD..) so
it *could* be done differently with -c, but the current behavior makes
more sense to me and matches the common case I'd use it for.
> If you think copy makes @{-1} problematic, perhaps your copy is
> doing more than it should (e.g. switching the current branch at the
> same time, or something).
I think what Sahil is getting at is asking where the @{-N} info is
stored and why this isn't equivalent to:
$ git checkout -b one master
$ git checkout -b two master
$ git checkout master
$ git checkout one
$ git checkout two
$ git checkout - # Goes to "one", not "master"
Which is in analogous flow without this feature that switches to the
last branch, but with "git branch -c" if you were on 'one' and copied
& checked out 'two' doing 'git checkout -' would bring you back to
'master', not 'one'.
Re: Git p4 sync changelist interval
On 6 June 2017 at 08:00, Luke Diamand wrote: > On 6 June 2017 at 00:29, Luke Diamand wrote: >> On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote: >>> 2017-06-04 14:09 GMT+03:00 Luke Diamand : > > The problem, as I see it, is that before syncing changes in the given > range, p4 task does not sync to cl1 version of the repo, and applies > commits to the empty repository. > Is it a bug or my misunderstanding of how git p4 should work? Possibly I'm misunderstanding what you're doing! Can you give a sequence of steps to show the problem? >>> >>> What I meant is: >>> >>> 1. Create p4 depot >>> 2. Add first.file (CL 2) >>> 3. Add second.file (at CL 3) >>> 4. Add third.file (at CL 4) >>> 5. Modify first.file (at CL 5) >>> 4. git-p4 clone //depot@3,5 >>> >>> In this case first.file, will not be represented in the repository. >> >> Hmmm, it's not working right for me. Although in my case I seem to be >> missing the second file. >> >> It's fine if I don't use the revision range "3,5". > > It's also fine if I do: > > git p4 sync //depot@3 > cd depot > git p4 rebase It seems to be something to do with the code around line 3395 that says: if self.changeRange == "@all": self.changeRange = "" elif ',' not in self.changeRange: It's finding a lower revision number with which to later call importHeadRevision(), but that only seems to be called if the revision range does *not* have a "," in it. As a result, we never actually call importHeadRevision() and so files end up missing. The obvious fix of fishing out the "@3" from the "@3,5" revision range works in this instance, but breaks some of the regression tests. Luke
Re: Git p4 sync changelist interval
2017-06-06 10:49 GMT+03:00 Luke Diamand : > On 6 June 2017 at 08:00, Luke Diamand wrote: >> On 6 June 2017 at 00:29, Luke Diamand wrote: >>> On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote: 2017-06-04 14:09 GMT+03:00 Luke Diamand : > > > > > > The problem, as I see it, is that before syncing changes in the given > > range, p4 task does not sync to cl1 version of the repo, and applies > > commits to the empty repository. > > Is it a bug or my misunderstanding of how git p4 should work? > > Possibly I'm misunderstanding what you're doing! Can you give a > sequence of steps to show the problem? What I meant is: 1. Create p4 depot 2. Add first.file (CL 2) 3. Add second.file (at CL 3) 4. Add third.file (at CL 4) 5. Modify first.file (at CL 5) 4. git-p4 clone //depot@3,5 In this case first.file, will not be represented in the repository. >>> >>> Hmmm, it's not working right for me. Although in my case I seem to be >>> missing the second file. >>> >>> It's fine if I don't use the revision range "3,5". >> >> It's also fine if I do: >> >> git p4 sync //depot@3 >> cd depot >> git p4 rebase > > It seems to be something to do with the code around line 3395 that says: > > if self.changeRange == "@all": > self.changeRange = "" > elif ',' not in self.changeRange: > > It's finding a lower revision number with which to later call > importHeadRevision(), but that only seems to be called if the revision > range does *not* have a "," in it. As a result, we never actually call > importHeadRevision() and so files end up missing. > > The obvious fix of fishing out the "@3" from the "@3,5" revision range > works in this instance, but breaks some of the regression tests. > > Luke I did the same change before and it worked for me. I'd like to find out if it is a bug (I think it is), a normal behavior or am I doing something wrong. So according to what you say, it is a bug. Andrew
my subject
Dear Talented, I am Talent Scout For Sony Pictures Animation, Present Sony Pictures Animation Movies a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story of Peter Rabbit (Peter Rabbit 2018) The Movie is Currently Filming (In Production) Please Note That There Will Be No Auditions, Traveling or Any Special / Professional Acting Skills, Since the Production of This Movie Will Be Done with our State of Art Computer -Generating Imagery Equipment. We Are Prepared to Pay the Total Sum of $560,000.00 USD. For More Information/Understanding, Please Write us on the E-Mail Below. CONTACT EMAIL: sonyp...@usa.com All Reply to: sonyp...@usa.com Note: Only the Response send to this mail will be Given a Prior Consideration. Talent Scout Becky Miles
Jó reggelt, Am Lindsay, barátságos vagyok, és úgy dönt, hogy üzenetet hagy neked, tudom, hogy sok mérföldre van.
Re: [PATCH] t3200: add test for single parameter passed to -m option
On Tue, Jun 6, 2017 at 3:27 AM, Junio C Hamano wrote:
> Sahil Dua writes:
>
>> Adds a test for the case when only one parameter is passed to '-m'
>> (move/rename) option.
>>
>> For example - if 'git branch -m bbb' is run, it should rename the
>> currently checked out branch to bbb. There was no test for this
>> particular case with only one parameter for -m option. However,
>> there's one similar test case for -M option.
>>
>> Signed-off-by: Sahil Dua
>> ---
>> t/t3200-branch.sh | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
>> index fe62e7c775da6..7504f14bc52f8 100755
>> --- a/t/t3200-branch.sh
>> +++ b/t/t3200-branch.sh
>> @@ -100,6 +100,14 @@ test_expect_success 'git branch -m n/n n should work' '
>> git reflog exists refs/heads/n
>> '
>>
>> +test_expect_success 'git branch -m bbb should rename checked out branch' '
>> + test_when_finished git branch -d bbb &&
>> + test_when_finished git checkout master &&
>> + git checkout -b aaa &&
>> + git branch -m bbb &&
>> + git reflog exists refs/heads/bbb
>> +'
>
> Looks almost good. Don't we want to also make sure that HEAD points
> at bbb branch, e.g.
>
> git symbolic-ref HEAD >actual &&
> echo refs/heads/bbb >expect &&
> test_cmp expect actual &&
>
> after the "do we have reflog for the bbb branch?" test?
>
> Also, I suspect that we care about the reflog that is moved to 'bbb'
> retains entries created for 'aaa'. So perhaps "reflog exists" needs
> to be replaced by something like
>
> git checkout -b aaa &&
> git commit --allow-empty -m "a new commit" &&
> git rev-parse aaa@{1} >expect &&
> git branch -m bbb &&
> # the topmost entry is about branch creation
> git rev-parse bbb@{2} >actual
>
> no?
Both of these changes make complete sense and in my opinion will
increase the quality of the tests if applied to the other tests too. I
notice that no other test for this (-m|-M) option checks if the branch
is actually checked out. Similarly, no other test checks if the
operation retains reflog entries. They just check if the new reflog
exists.
Do you think I should make similar changes to the other tests for
(-m|-M) option as well?
>
>> test_expect_success 'git branch -m o/o o should fail when o/p exists' '
>> git branch o/o &&
>> git branch o/p &&
>>
>> --
>> https://github.com/git/git/pull/371
Re: What's cooking in git.git (Jun 2017, #03; Mon, 5)
On Mon, Jun 5, 2017 at 8:23 PM, Stefan Beller wrote: > > > [...] > > "git diff" has been taught to optionally paint new lines that are > > the same as deleted lines elsewhere differently from genuinely new > > lines. > > > > Are we happy with these changes? I've been studiously ignoring this patch series due to lack of bandwidth. > [...] > Things to come, but not in this series as they are more advanced: > > Discuss if a block/line needs a minimum requirement. > > When doing reviews with this series, a couple of lines such > as "\t\t}" were marked as a moved, which is not wrong as they > really occurred in the text with opposing sign. > But it was annoying as it drew my attention to just closing > braces, which IMO is not the point of code review. > > To solve this issue I had the idea of a "minimum requirement", e.g. > * at least 3 consecutive lines or > * at least one line with at least 3 non-ws characters or > * compute the entropy of a given moved block and if it is too low, do > not mark it up. Shooting from the hip here... It seems obvious that for a line to be marked as moved, a minimum requirement is that 1. The line appears as both "+" and "-". That doesn't seem strong enough evidence though, and if that is the only criterion, I would expect a lot of boilerplate lines like "\t\t}" to be marked as moved. It seems like a lot of noise could be eliminated by *also* requiring that 2a. The line doesn't appear elsewhere in the file(s) concerned. Rule (2a) would probably get rid of most boilerplate lines without having to try to measure entropy. Maybe you are already using both criteria? I didn't see it in a quick perusal of the code. OTOH, it would be silly to refuse to mark lines like "\t\t}" as moved *only* because they appear elsewhere in the file(s). If you did so, you would have gaps of supposedly non-moved lines in the middle of moved blocks. This suggests marking as moved lines matching (1) and (2a) but also lines matching (1) and the following: 2b. The line is adjacent to to another line that is thought to have moved from the same old location to the same new location. Rule (2b) would be applied recursively, with the net effect being that any line satisfying (1) and (2a) is allowed to carry along any neighboring lines within the same "+"/"-" block even if they are not unique. Michael
Re: Git v2.13.1 SHA1 very broken
On Tue, Jun 06, 2017 at 10:20:45AM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > That looks scary, can you please comment out this: > > > > #define SHA1DC_ALLOW_UNALIGNED_ACCESS > > > > In sha1dc/sha1.c and see if that helps, alternatively comment out the > > ifdefs guarded by "#ifdef _MSC_VER" calls in sha1dc/sha1.c > > That is merely a performance (and theoretical correctness) thing, > no? Confirmed rebuilding with either of these suggested changes has t.46 still failing. > > The functional differences between 2.13.0 and 2.13.1 on that platform > > should be none aside from possibly those changes, unless I've missed > > something. > > If it does not hash correctly, the cause is more likely that the > endianness detection is going haywire. > > make CFLAGS="-DSHA1DC_FORCE_LITTLEENDIAN -g -O2 -Wall" Confirmed rebuilding with this option has t passing. I can also get the test to pass with Ramsay Jones' suggestion of using OpenSSL's SHA1. Digging briefly into the endianness detection, it appears Cygwin has both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by assuming it's in a little endian environment and switching to big endian if it detects any of the defines that indicate such, and a010391 adds _BIG_ENDIAN to the set of defines that indicate big endianness. The obvious quick fix would be one of the two below patches. I'll also take the discussion to the Cygwin mailing list in the hope that someone can explain why Cygwin defines both _LITTLE_ENDIAN and _BIG_ENDIAN (and indeed _PDP_ENDIAN). Patch 1 (probably safer?): diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c index 3dff80ac7..e47d004b1 100644 --- a/sha1dc/sha1.c +++ b/sha1dc/sha1.c @@ -36,6 +36,7 @@ #undef SHA1DC_BIGENDIAN #endif #if (!defined SHA1DC_FORCE_LITTLEENDIAN) && \ +(!defined _LITTLE_ENDIAN) && \ ((defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || \ (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __BIG_ENDIAN__)) || \ defined(_BIG_ENDIAN) || defined(__BIG_ENDIAN__) || defined(__ARMEB__) || defined(__THUMBEB__) || defined(__AARCH64EB__) || \ Patch 2: diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c index 3dff80ac7..8d7b1ee7d 100644 --- a/sha1dc/sha1.c +++ b/sha1dc/sha1.c @@ -38,7 +38,7 @@ #if (!defined SHA1DC_FORCE_LITTLEENDIAN) && \ ((defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || \ (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __BIG_ENDIAN__)) || \ -defined(_BIG_ENDIAN) || defined(__BIG_ENDIAN__) || defined(__ARMEB__) || defined(__THUMBEB__) || defined(__AARCH64EB__) || \ +defined(__BIG_ENDIAN__) || defined(__ARMEB__) || defined(__THUMBEB__) || defined(__AARCH64EB__) || \ defined(_MIPSEB) || defined(__MIPSEB) || defined(__MIPSEB__) || defined(SHA1DC_FORCE_BIGENDIAN)) #define SHA1DC_BIGENDIAN
Re: [PATCH/RFC v4 3/3] branch: add copy branch feature implementation
On Tue, Jun 6, 2017 at 9:39 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Tue, Jun 6, 2017 at 2:10 AM, Junio C Hamano wrote:
>> Sahil Dua writes:
>>
>>> I want suggestions about one logical point raised by Evar.
>>>
>>> Let's consider a case that I'm on branch maint and then I do 'git
>>> checkout master' followed by 'git branch -m feature', it will rename
>>> master branch to feature. Now if I do 'git checkout -' to go to the
>>> last branch, it will take me to maint since master branch doesn't
>>> exist in this case.
>>>
>>> Now, for this copy operation - if I'm on branch maint and then I do
>>> 'git checkout master' followed by 'git branch -c feature', it will
>>> copy master branch to feature. Now if I do 'git checkout -' to go to
>>> the last branch, it will again go to maint (according to the current
>>> implementation). What do you think it should do? Is this the desired
>>> behavior? Or should it go to master branch since that was the branch
>>> checked out before copying.
>>>
>>> Also, in case this needs to be changed, can someone please point me to
>>> how it's being handled so that I can change the behavior.
>>
>> When somebody says "I want to rename my current branch to X", it is
>> clear that the person wants to end up being on a branch called X.
>>
>> To me, "I want to copy my current branch to Y" sounds more like "I
>> want to create another Y that looks just like the current branch,
>> but I want stay on my current branch".
>
> This would be more useful to me if the semantics were copy & checkout
> instead of just copy, since when I'd like to copy branches it's almost
> always because I'm on some topic branch and want to create & work on a
> new copy of that topic branch.
>
> It would also be consistent with "git branch -m" and easier to
> explain, i.e. "git branch -c just like -m except it doesn't delete the
> branch name/config you moved away from".
>
> Like with -m, you can still move around random other branches, e.g.:
>
> # While on master
> $ git branch -m some-other new-some-other
>
> This will just move some-other to new-some-other without checkout out
> new-some-other, it's only when the source name is the same as your
> currently checked out branch that you checkout a new branch,
>
> Now, of course the difference is that when you -m your current branch
> it doesn't really have a choice of whether to move your checkout as
> well (although I suppose it could leave you in a detached HEAD..) so
> it *could* be done differently with -c, but the current behavior makes
> more sense to me and matches the common case I'd use it for.
>
>> If you think copy makes @{-1} problematic, perhaps your copy is
>> doing more than it should (e.g. switching the current branch at the
>> same time, or something).
>
> I think what Sahil is getting at is asking where the @{-N} info is
> stored and why this isn't equivalent to:
>
> $ git checkout -b one master
> $ git checkout -b two master
> $ git checkout master
> $ git checkout one
> $ git checkout two
> $ git checkout - # Goes to "one", not "master"
>
> Which is in analogous flow without this feature that switches to the
> last branch, but with "git branch -c" if you were on 'one' and copied
> & checked out 'two' doing 'git checkout -' would bring you back to
> 'master', not 'one'.
Yes, indeed. I am not sure how @{-N} info is stored and why it's not
doing the expected thing. Expected thing here will be to go to the
original branch from where you copied the new branch if you run 'git
checkout -'.
Re: Git p4 sync changelist interval
On 6 June 2017 at 08:56, Андрей Ефанов <1134t...@gmail.com> wrote: >> >> It seems to be something to do with the code around line 3395 that says: >> >> if self.changeRange == "@all": >> self.changeRange = "" >> elif ',' not in self.changeRange: >> >> It's finding a lower revision number with which to later call >> importHeadRevision(), but that only seems to be called if the revision >> range does *not* have a "," in it. As a result, we never actually call >> importHeadRevision() and so files end up missing. >> >> The obvious fix of fishing out the "@3" from the "@3,5" revision range >> works in this instance, but breaks some of the regression tests. >> >> Luke > > I did the same change before and it worked for me. I'd like to find > out if it is a bug (I think it is), a normal behavior or am I doing > something wrong. > > So according to what you say, it is a bug. It's a bug! I think you can workaround it by doing: $ git p4 clone //depot@3 $ git p4 sync I'll see if I can workout why my obvious fix caused the tests to fail.
Re: What does this output of git supposed to mean ?
From: "David" On 6 June 2017 at 11:52, Junio C Hamano wrote: Samuel Lijin writes: For what it's worth, I've never quite understood the "Initial commit" message, because the repository is in a state where there are no commits yet, not when HEAD is pointing to a root commit. In the context of "status", it probably is more logically correct if it said "No commit yet" or something. This is no longer "is initial harder than root?" ;-) Exactly. I agree with OP, in the context of running 'git status', I find the string "Initial commit" confusing in the example below, because at that time no commits exist. This creates confusion what git is talking about. The 'git log' message is not very friendly either. Perhaps say something like "Repository is empty." there. I like that. I think that is a very appropriately descriptive statement. An alternative ,with slightly less textual change, could be "Waiting for initial commit" $ mkdir test $ cd test $ git init Initialized empty Git repository in /mnt/hart/home/david_d08/junk/test/.git/ $ git log fatal: bad default revision 'HEAD' $ git status On branch master Initial commit nothing to commit (create/copy files and use "git add" to track)
Re: What does this output of git supposed to mean ?
> >> In the context of "status", it probably is more logically correct if > >> it said "No commit yet" or something. This is no longer "is initial > >> harder than root?" ;-) > > > > Exactly. I agree with OP, in the context of running 'git status', I find > > the string "Initial commit" confusing in the example below, because > > at that time no commits exist. This creates confusion what git is > > talking about. The 'git log' message is not very friendly either. > > > > Perhaps say something like "Repository is empty." there. > > > I like that. I think that is a very appropriately descriptive statement. > > An alternative ,with slightly less textual change, could be "Waiting for > initial commit" > We should consider orphan/unborn branches, too: git (master)$ git checkout --orphan newroot Switched to a new branch 'newroot' git (newroot +)$ git reset --hard git (newroot #)$ git status On branch newroot Initial commit nothing to commit (create/copy files and use "git add" to track) A purely textual change will not be sufficient, I'm afraid. Saying "Repository is empty" right after 'git init' is fine, I like it. However, on an unborn branch with empty index it would be just wrong. "Waiting for initial commit" is much better even in this case, but I still don't like that "initial", though I can't say why, and don't have any better suggestion either. Though users experienced enough to create an empty unborn branch would probably not be confused by that.
Re: What does this output of git supposed to mean ?
"Philip Oakley" writes: > From: "David" > >> Perhaps say something like "Repository is empty." there. > > > I like that. I think that is a very appropriately descriptive statement. > > An alternative ,with slightly less textual change, could be "Waiting > for initial commit" > I can buy that one. I do not want to see "Repository is empty", as that will open us up to criticism that we are being sloppy and technically incorrect to cater to newbies (i.e. we will give the message if you do "checkout --orphan", and repository is definitely not empty in that case). "Waiting for the initial commit", or "No commits yet", can be explained to describe the state of the current branch (not the state of the repository), and it is correct that we do not have any commit on the branch, and the branch is waiting for the initial commit.
Re: Git v2.13.1 SHA1 very broken
Adam Dinwoodie writes: > Digging briefly into the endianness detection, it appears Cygwin has > both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by > assuming it's in a little endian environment and switching to big endian > if it detects any of the defines that indicate such, and a010391 adds > _BIG_ENDIAN to the set of defines that indicate big endianness. I suspect that the upstream has already fixed this one to cope with FreeBSD. My preference is that we do another import on top of the ab/sha1dc-maint topic, below the commit on ab/sha1dc that adds the upstream as a submodule.
Re: [PATCH/RFC v4 3/3] branch: add copy branch feature implementation
Ævar Arnfjörð Bjarmason writes: > On Tue, Jun 6, 2017 at 2:10 AM, Junio C Hamano wrote: > >> When somebody says "I want to rename my current branch to X", it is >> clear that the person wants to end up being on a branch called X. >> >> To me, "I want to copy my current branch to Y" sounds more like "I >> want to create another Y that looks just like the current branch, >> but I want stay on my current branch". > > This would be more useful to me if the semantics were copy & checkout > instead of just copy, since when I'd like to copy branches it's almost > always because I'm on some topic branch and want to create & work on a > new copy of that topic branch. > > It would also be consistent with "git branch -m" and easier to > explain, i.e. "git branch -c just like -m except it doesn't delete the > branch name/config you moved away from". The way I would use this feature, I'd imagine, would be to stash away the current state of the branch before I try to do something potentially stupid, and then recover the original state by reverting back, i.e. $ git branch -c master backup ... do silly things to the master branch ... ... ok, enough silliness. go back to sane state ... $ git branch -M backup master Having said that, I think it is merely the matter of personal taste and there is no single "right" definition. I do not have a strong feeling either way. To play devil's advocate, I'd anticipate a criticism, if we take your interpretation (which I do not _mind_, even though I do not have strong feeling _for_ it), saying "I just told you to _copy_ it. If I wanted to check it out, I'd do that myself. Why are you doing more than I asked, stupid Git." I have to say upfront that against such a criticism, I won't defend your position myself.
Re: Git v2.13.1 SHA1 very broken
On Tue, Jun 06, 2017 at 08:55:04PM +0900, Junio C Hamano wrote:
> Adam Dinwoodie writes:
>
> > Digging briefly into the endianness detection, it appears Cygwin has
> > both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by
> > assuming it's in a little endian environment and switching to big endian
> > if it detects any of the defines that indicate such, and a010391 adds
> > _BIG_ENDIAN to the set of defines that indicate big endianness.
>
> I suspect that the upstream has already fixed this one to cope with
> FreeBSD. My preference is that we do another import on top of the
> ab/sha1dc-maint topic, below the commit on ab/sha1dc that adds the
> upstream as a submodule.
Apparently so! a010391 brings Git up to the upstream's cc46554 ("Skip
temporary variable for SHA1DC_ALLOW_UNSIGNED_ACCESS", 2017-05-18); the
problem has been fixed in upstream's a24eef5 ("rewrote Endianness
selection", 2017-05-29).
In the interim, I'll use the CFLAGS route to try to get a v2.13.1 build
ready to release for Cygwin.
Re: Git v2.13.1 SHA1 very broken
One could have configure ask some existing dependency that has already
determined the byte order. For example:
# perl -e 'use Config; $o=$Config{byteorder}; print(($o=~/^1234/ ?
"little" : ($o=~/4321$/ ? "big" : "weird")), "\n");'
little
Good: less #ifdef soup; bad: not so great for cross-compiling.
(That's the integer byte order. The floating-point byte order can be different;
hopefully git doesn't care.)
Morten
On Tue, Jun 6, 2017 at 7:55 AM, Junio C Hamano wrote:
> Adam Dinwoodie writes:
>
>> Digging briefly into the endianness detection, it appears Cygwin has
>> both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by
>> assuming it's in a little endian environment and switching to big endian
>> if it detects any of the defines that indicate such, and a010391 adds
>> _BIG_ENDIAN to the set of defines that indicate big endianness.
>
> I suspect that the upstream has already fixed this one to cope with
> FreeBSD. My preference is that we do another import on top of the
> ab/sha1dc-maint topic, below the commit on ab/sha1dc that adds the
> upstream as a submodule.
>
Re: [PATCH] docs: suggest "Helped-by" rather than "Thanks-to"
On Mon, Jun 05, 2017 at 11:42:31AM -0700, Stefan Beller wrote: > So I was wondering if there is a command that shows all trailers? > Similar to a "shortlog -sne" I would want to have a list of all trailers. > This is because there might be an even more popular trailer than > "Helped-by", but we would not know when using the hack above. > > While I do not think so, it would sure be interesting to have a list > of all these trailers available. I just did a quick search with the following knocked-together command: git log --remotes --format=format:%B | sed -rn 's/^([A-Za-z0-9-]+): .* <.*@.*>.*/\1/p' | sort | uniq -c | sort -nr The top 10 such tags according to this (which is coincidentally the same list as the list of all tags used more than 100 times), with frequencies, are: 61535 Signed-off-by 1641 Acked-by 984 Reviewed-by 673 Helped-by 497 Reported-by 180 Cc 174 Suggested-by 159 Tested-by 158 Mentored-by 128 Noticed-by As you might expect, there are a number of entertaining ones that have only been used once or twice, such as "Looks-fine-to-me-by", "Worriedly-Acked-by", "More-Spots-Found-By", "Looks-right-to-me-by", "Hopefully-signed-off-by"...
Feature request: Please add support to stash specific files
git version 2.6.3 OS: RHEL 6 Work around found in: https://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git Workaround is not very optimal. Please add this support to git. -- == Rajdeep ==
RE: Feature request: Please add support to stash specific files
-Original Message- On June 6, 2017 9:23 AM, rajdeep mondal wrote: >Work around found in: >https://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git >Workaround is not very optimal. Please add this support to git. Instead of using stash as part of your normal process, consider using topic branches instead. Before working, switch to a new topic branch. If you forget, stash, switch, apply, then go forth. While on the topic branch, you can use add and commit on a hunk or file basis to satisfy what appears to be the requirement here. You can then merge the desired commits from your topic branch into wherever you want to merge them either preserving the commit or by squashing commits together. In my shop, stash is only used for the "I forgot to switch to a topic branch, oops" process. I try to encourage people not to use it. I also discourage squashed commits, but that's because I like knowing what's in my sausages 😊 Cheers, Randall
Re: Feature request: Please add support to stash specific files
rajdeep mondal writes: > git version 2.6.3 > OS: RHEL 6 > > Work around found in: > https://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git > > Workaround is not very optimal. Please add this support to git. This has been implemented in Git 2.13: > * "git stash push" takes a pathspec so that the local changes can be > stashed away only partially. -- Christian Neukirchenhttp://chneukirchen.org
Re: What does this output of git supposed to mean ?
On Tue, 2017-06-06 at 20:52 +0900, Junio C Hamano wrote: > "Waiting for the initial commit", or "No commits yet", can be > explained to describe the state of the current branch (not the state > of the repository), and it is correct that we do not have any commit > on the branch, and the branch is waiting for the initial commit. > Looks descriptive to me too. Just for the note, I wouldn't have asked this question if `git status` showed a message like this. -- Regards, Kaartic Sivaraam
Continous Integration (was: RE: Git v2.13.1 SHA1 very broken)
Do we have Jenkins (or something else) setup for Git? We would be happy to donate (slave) VMs for cygwin builds og Git. -Jason Pyeron
Re: Continous Integration (was: RE: Git v2.13.1 SHA1 very broken)
> On 06 Jun 2017, at 16:47, Jason Pyeron wrote: > > Do we have Jenkins (or something else) setup for Git? > > We would be happy to donate (slave) VMs for cygwin builds og Git. > > -Jason Pyeron > We use TravisCI for Linux, Mac, and (in a special way) Windows: https://travis-ci.org/git/git Windows is not supported by TravisCI. We just use TravisCI to trigger a build on MS Azure and read the results: https://github.com/git/git/commit/029aeeed55f6bfe8014e8ffe5fc7a6f2e5b110fc Maybe we could trigger a Cgywin build on your slaves in the same way? - Lars
[PATCH 1/3] sha1dc: update from upstream
Update sha1dc from the latest version by the upstream
maintainer[1].
See commit a0103914c2 ("sha1dc: update from upstream", 2017-05-20) for
the latest update. That update was done sans some whitespace changes
by upstream, which is why the diff here isn't the same as the upstream
cc46554..e139984.
It also brings in a change[2] upstream made which should hopefully
address the breakage in 2.13.1 on Cygwin, see [3]. Cygwin defines both
_BIG_ENDIAN and _LITTLE_ENDIAN.
Adam Dinwoodie reports on the mailing list that that upstream commit
fixes the issue on Cygwin[4].
1.
https://github.com/cr-marcstevens/sha1collisiondetection/commit/e1399840b501a68ac6c8d7ed9a5cb1455480200e
2.
https://github.com/cr-marcstevens/sha1collisiondetection/commit/a24eef58c0684078405f8c7a89f9b78271432005
3. <20170606100355.gc25...@dinwoodie.org>
(https://public-inbox.org/git/20170606100355.gc25...@dinwoodie.org/)
4. <20170606124323.gd25...@dinwoodie.org>
(https://public-inbox.org/git/20170606124323.gd25...@dinwoodie.org/)
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1dc/sha1.c | 30 --
sha1dc/sha1.h | 6 +++---
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c
index 3dff80ac72..facea1bb56 100644
--- a/sha1dc/sha1.c
+++ b/sha1dc/sha1.c
@@ -35,15 +35,33 @@
#ifdef SHA1DC_BIGENDIAN
#undef SHA1DC_BIGENDIAN
#endif
-#if (!defined SHA1DC_FORCE_LITTLEENDIAN) && \
-((defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || \
-(defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __BIG_ENDIAN__)) || \
-defined(_BIG_ENDIAN) || defined(__BIG_ENDIAN__) || defined(__ARMEB__) ||
defined(__THUMBEB__) || defined(__AARCH64EB__) || \
-defined(_MIPSEB) || defined(__MIPSEB) || defined(__MIPSEB__) ||
defined(SHA1DC_FORCE_BIGENDIAN))
+#if (defined(_BYTE_ORDER) || defined(__BYTE_ORDER) || defined(__BYTE_ORDER__))
+
+#if ((defined(_BYTE_ORDER) && (_BYTE_ORDER == _BIG_ENDIAN)) || \
+ (defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || \
+ (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __BIG_ENDIAN__)) )
#define SHA1DC_BIGENDIAN
+#endif
+
+#else
+
+#if (defined(_BIG_ENDIAN) || defined(__BIG_ENDIAN) || defined(__BIG_ENDIAN__)
|| \
+ defined(__ARMEB__) || defined(__THUMBEB__) || defined(__AARCH64EB__) || \
+ defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || \
+ defined(__sparc))
+#define SHA1DC_BIGENDIAN
+#endif
-#endif /*ENDIANNESS SELECTION*/
+#endif
+
+#if (defined(SHA1DC_FORCE_LITTLEENDIAN) && defined(SHA1DC_BIGENDIAN))
+#undef SHA1DC_BIGENDIAN
+#endif
+#if (defined(SHA1DC_FORCE_BIGENDIAN) && !defined(SHA1DC_BIGENDIAN))
+#define SHA1DC_BIGENDIAN
+#endif
+/*ENDIANNESS SELECTION*/
#if (defined SHA1DC_FORCE_UNALIGNED_ACCESS || \
defined(__amd64__) || defined(__amd64) || defined(__x86_64__) ||
defined(__x86_64) || \
diff --git a/sha1dc/sha1.h b/sha1dc/sha1.h
index a0ff5d1305..1e4e94be54 100644
--- a/sha1dc/sha1.h
+++ b/sha1dc/sha1.h
@@ -61,9 +61,9 @@ void SHA1DCInit(SHA1_CTX*);
Function to enable safe SHA-1 hashing:
Collision attacks are thwarted by hashing a detected near-collision block
3 times.
Think of it as extending SHA-1 from 80-steps to 240-steps for such blocks:
- The best collision attacks against SHA-1 have complexity about 2^60,
- thus for 240-steps an immediate lower-bound for the best cryptanalytic
attacks would be 2^180.
- An attacker would be better off using a generic birthday search of
complexity 2^80.
+The best collision attacks against SHA-1 have complexity about 2^60,
+thus for 240-steps an immediate lower-bound for the best cryptanalytic
attacks would be 2^180.
+An attacker would be better off using a generic birthday search of
complexity 2^80.
Enabling safe SHA-1 hashing will result in the correct SHA-1 hash for
messages where no collision attack was detected,
but it will result in a different SHA-1 hash for messages where a collision
attack was detected.
--
2.13.0.506.g27d5fe0cd
[PATCH 2/3] sha1dc: optionally use sha1collisiondetection as a submodule
Add an option to use the sha1collisiondetection library from the submodule in sha1collisiondetection/ instead of in the copy in the sha1dc/ directory. This allows us to try out the submodule in sha1collisiondetection without breaking the build for anyone who's not expecting them as we work out any kinks. Signed-off-by: Ævar Arnfjörð Bjarmason --- .gitmodules| 4 Makefile | 12 hash.h | 4 sha1collisiondetection | 1 + 4 files changed, 21 insertions(+) create mode 100644 .gitmodules create mode 16 sha1collisiondetection diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 00..cbeebdab7a --- /dev/null +++ b/.gitmodules @@ -0,0 +1,4 @@ +[submodule "sha1collisiondetection"] + path = sha1collisiondetection + url = https://github.com/cr-marcstevens/sha1collisiondetection.git + branch = master diff --git a/Makefile b/Makefile index 7c621f7f76..adeff26d57 100644 --- a/Makefile +++ b/Makefile @@ -146,6 +146,12 @@ all:: # algorithm. This is slower, but may detect attempted collision attacks. # Takes priority over other *_SHA1 knobs. # +# Define DC_SHA1_SUBMODULE in addition to DC_SHA1 to use the +# sha1collisiondetection shipped as a submodule instead of the +# non-submodule copy in sha1dc/. This is an experimental option used +# by the git project to migrate to using sha1collisiondetection as a +# submodule. +# # Define OPENSSL_SHA1 environment variable when running make to link # with the SHA1 routine from openssl library. # @@ -1416,8 +1422,14 @@ ifdef APPLE_COMMON_CRYPTO BASIC_CFLAGS += -DSHA1_APPLE else DC_SHA1 := YesPlease +ifdef DC_SHA1_SUBMODULE + LIB_OBJS += sha1collisiondetection/lib/sha1.o + LIB_OBJS += sha1collisiondetection/lib/ubc_check.o + BASIC_CFLAGS += -DDC_SHA1_SUBMODULE +else LIB_OBJS += sha1dc/sha1.o LIB_OBJS += sha1dc/ubc_check.o +endif BASIC_CFLAGS += \ -DSHA1_DC \ -DSHA1DC_NO_STANDARD_INCLUDES \ diff --git a/hash.h b/hash.h index a11fc9233f..bef3e630a0 100644 --- a/hash.h +++ b/hash.h @@ -8,7 +8,11 @@ #elif defined(SHA1_OPENSSL) #include #elif defined(SHA1_DC) +#ifdef DC_SHA1_SUBMODULE +#include "sha1collisiondetection/lib/sha1.h" +#else #include "sha1dc/sha1.h" +#endif #else /* SHA1_BLK */ #include "block-sha1/sha1.h" #endif diff --git a/sha1collisiondetection b/sha1collisiondetection new file mode 16 index 00..e1399840b5 --- /dev/null +++ b/sha1collisiondetection @@ -0,0 +1 @@ +Subproject commit e1399840b501a68ac6c8d7ed9a5cb1455480200e -- 2.13.0.506.g27d5fe0cd
[PATCH 0/3] update sha1dc
This updates sha1dc fixing the issue on Cygwin introduced in 2.13.1, and hopefully not regressing elsewhere. Liam, it would be much appreciated if you could test this on SPARC. As before the "sha1dc: update from upstream" patch is what should fast-track to master/maint and be in 2.13.2, the other two are the cooking submodule use, that's all unchanged aside from of course the submodule pointing to the same upstream commit as the code import itself does. Junio: There's a whitespace change to sha1.h that am warns about, but which it applies anyway that you didn't apply from my previous patch. I think it probably makes sense to just take upstream's whitespace shenanigans as-is instead of seeing that diff every time we update. I guess we could also send them a pull request... Junio C Hamano (1): sha1collisiondetection: automatically enable when submodule is populated Ævar Arnfjörð Bjarmason (2): sha1dc: update from upstream sha1dc: optionally use sha1collisiondetection as a submodule .gitmodules| 4 Makefile | 16 hash.h | 4 sha1collisiondetection | 1 + sha1dc/sha1.c | 30 -- sha1dc/sha1.h | 6 +++--- 6 files changed, 52 insertions(+), 9 deletions(-) create mode 100644 .gitmodules create mode 16 sha1collisiondetection -- 2.13.0.506.g27d5fe0cd
[PATCH 3/3] sha1collisiondetection: automatically enable when submodule is populated
From: Junio C Hamano If a user wants to experiment with the version of collision detecting sha1 from the submodule, the user needed to not just populate the submodule but also needed to turn the knob. A Makefile trick is easy enough to do so, so let's do this. When somebody with a copy of the submodule populated wants not to use it, that can be done by overriding it in config.mak or from the command line. Signed-off-by: Junio C Hamano Signed-off-by: Ævar Arnfjörð Bjarmason --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index adeff26d57..eeccbff1cd 100644 --- a/Makefile +++ b/Makefile @@ -993,6 +993,10 @@ EXTLIBS = GIT_USER_AGENT = git/$(GIT_VERSION) +ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h) +DC_SHA1_SUBMODULE = auto +endif + include config.mak.uname -include config.mak.autogen -include config.mak -- 2.13.0.506.g27d5fe0cd
Re: Git "Keeping Original Dates"
On Mon, Jun 05, 2017 at 07:36:58PM -0400, Hector Santos wrote: > Do you see any technical issues with using programmable hooks or something > like this would have to be patched in? I am giving it a serious thought to > exploring a fix to the Git Daemon over the wire completion issues on > Windows. It appears to be a Half Close socket issue. You can certainly do it with so kind of hook script. This is how I do thing to maintain the modtimes for a set of patches that I maintain using guilt (git://repo.or.cz/guilt.git). The following is done using Linux, but I imagine you could translate it into something that would work with powershell, or cygwin, or just use the Windows Subsystem for Linux. #!/bin/sh stat -c "touch -d @%Y %n" * | sort -k 3 | grep -v "~$" | sort -k3 > timestamps I have this shell script saved as ~/bin/save-timestamps. The generated file has lines which look this: touch -d @1496078695 fix-fdatasync-after-extent-manipulation-operations touch -d @1496081597 status touch -d @1496082752 series ... and when you execute the command, it will restore the timestamps to the value checked into the git repository. If you want to only restore the timestamp of a single file, you can do something like this: grep timestamps ^fix-fdatasync-after-extent | bash Cheers, - Ted
[BUG] Help > About Git Gui = crash
Reproduction: - Start git gui - Go to menu panel: Help > About Git Gui Output: error: git-gui died of signal 11 Environment: Debian 8 jessie amd64 KDE -- Regards, Konstantin Podsvirov
Re: [BUG?] gitlink without .gitmodules no longer fails recursive clone
On Mon, Jun 5, 2017 at 8:56 PM, Jeff King wrote: > While running some regression tests with v2.13, I noticed an odd > behavior. If I create a repository where there's a gitlink with no > matching .gitmodules entry: > > git init repo > cd repo > n10=1234abcdef > n40=$n10$n10$n10$n10 > git update-index --add --cacheinfo 16 $n40 foo > git commit -m "gitlink without .gitmodule entry" > > and then I clone it recursively with v2.12, it fails: > > $ git.v2.12.3 clone --recurse-submodules . dst; echo exit=$? > Cloning into 'dst'... > done. > fatal: No url found for submodule path 'foo' in .gitmodules > exit=128 > > But with v2.13, it silently ignores the submodule: > > $ git.v2.13.1 clone --recurse-submodules . dst; echo exit=$? > Cloning into 'dst'... > done. > exit=0 > > This bisects to your bb62e0a99 (clone: teach --recurse-submodules to > optionally take a pathspec, 2017-03-17). That patch just sets > submodule.active by default, so I think the real issue is probably in > a086f921a (submodule: decouple url and submodule interest, 2017-03-17). It's a feature, not a bug, IMO. When starting out the journey to improve submodules, one of the major principle was to not interfere with gitlinks too much, as they are used in ways git cannot fathom (cf git-series storing patches in gitlink form). And building on that: You asked for recursing into *submodules*, not into *gitlinks*. And submodules in the new Git have stronger requirements w.r.t. the gitmodules file. (You have to tell us exactly how you want your submodule to be treated, and we do not want to half-ass guess around the shortcomings of a user not telling us about the submodule) > I also wasn't sure if this might be intentional. I.e., that we'd just > consider gitlink entries which aren't even configured as not-submodules > and ignore them. I think this is what we want to do, and we should do it consistently. The only downside for this is that more unintentional gitlinks may be added to repositories as Git will be very good at ignoring them. > I couldn't certainly see an argument for moving in that > direction, but it is different than what we used to do. But I couldn't > find anything in any of the commit messages that mentioned this either > way, so I figured I'd punt and ask. :) Yeah, yesterday we had a big discussion if we want to publish our roadmap and long term vision (as a team, as a company, or as a community?) This would help newcomers and outsiders to see where e.g. submodules are headed and people could speak up early if we miss their use case. Thanks for asking, Stefan > > -Peff
Re: [BUG?] gitlink without .gitmodules no longer fails recursive clone
On 06/06, Stefan Beller wrote: > On Mon, Jun 5, 2017 at 8:56 PM, Jeff King wrote: > > While running some regression tests with v2.13, I noticed an odd > > behavior. If I create a repository where there's a gitlink with no > > matching .gitmodules entry: > > > > git init repo > > cd repo > > n10=1234abcdef > > n40=$n10$n10$n10$n10 > > git update-index --add --cacheinfo 16 $n40 foo > > git commit -m "gitlink without .gitmodule entry" > > > > and then I clone it recursively with v2.12, it fails: > > > > $ git.v2.12.3 clone --recurse-submodules . dst; echo exit=$? > > Cloning into 'dst'... > > done. > > fatal: No url found for submodule path 'foo' in .gitmodules > > exit=128 > > > > But with v2.13, it silently ignores the submodule: > > > > $ git.v2.13.1 clone --recurse-submodules . dst; echo exit=$? > > Cloning into 'dst'... > > done. > > exit=0 > > > > This bisects to your bb62e0a99 (clone: teach --recurse-submodules to > > optionally take a pathspec, 2017-03-17). That patch just sets > > submodule.active by default, so I think the real issue is probably in > > a086f921a (submodule: decouple url and submodule interest, 2017-03-17). > > It's a feature, not a bug, IMO. > > When starting out the journey to improve submodules, one of the major > principle was to not interfere with gitlinks too much, as they are used in > ways git cannot fathom (cf git-series storing patches in gitlink form). > > And building on that: You asked for recursing into *submodules*, not > into *gitlinks*. And submodules in the new Git have stronger requirements > w.r.t. the gitmodules file. (You have to tell us exactly how you want your > submodule to be treated, and we do not want to half-ass guess around > the shortcomings of a user not telling us about the submodule) Just for some background on the new behavior and how this functionality changed: My series changed how 'submodule init' behaved if you have 'submodule.active' set. Once set (like how clone --recurse does now) when not provided any path to a submodule, a list of 'active' submodules matching the 'submodule.active' pathspec will be initialized. One of the requirements to be 'active' is to have an entry in the .gitmodules file so gitlinks without an entry in the .gitmodules file will simply be ignored now. > > > I also wasn't sure if this might be intentional. I.e., that we'd just > > consider gitlink entries which aren't even configured as not-submodules > > and ignore them. > > I think this is what we want to do, and we should do it consistently. > The only downside for this is that more unintentional gitlinks may be > added to repositories as Git will be very good at ignoring them. > > > I couldn't certainly see an argument for moving in that > > direction, but it is different than what we used to do. But I couldn't > > find anything in any of the commit messages that mentioned this either > > way, so I figured I'd punt and ask. :) > > Yeah, yesterday we had a big discussion if we want to publish our > roadmap and long term vision (as a team, as a company, or as a > community?) This would help newcomers and outsiders to see where > e.g. submodules are headed and people could speak up early if we miss > their use case. > > Thanks for asking, > Stefan > > > > > -Peff -- Brandon Williams
Re: [PATCHv4 1/2] clone: respect additional configured fetch refspecs during initial fetch
On Mon, Jun 5, 2017 at 10:18 AM, Jeff King wrote:
> Yeah, I agree it is safe now. I'm just worried about some function in
> remote.c later doing:
>
>read_config();
>add_and_parse_fetch_refspec(remotes[0], whatever);
>
> which leaves the struct in an inconsistent state (we realloc NULL which
> allocates from scratch, and all of the other entries in remote->fetch
> end up uninitialized). Can we at least add an assertion like:
>
> if (!remote->fetch)
> BUG("cannot add refspec to an unparsed remote");
>
> ?
But as mentioned before, remote->fetch being NULL is not a bug in
itself, it's a perfectly valid value even in a fully parsed remote
when the remote has no fetch refspecs.
Therefore, I think, the condition should instead be:
remote->fetch_refspec_nr && !remote->fetch
We could even try to be extra helpful by checking this condition and
calling parse_fetch_refspec() to initialize remote->fetch instead of
BUG()ing out. However, that would mask the real issue, namely not
using remote_get() to get the remote, so I don't actually think that's
a good thing to do.
OTOH, having remote->fetch so closely related to, yet separate from
remote->fetch_refspec{,_nr,_alloc} will always inherently be error
prone. This assertion would catch one case where a less than careful
dev could cause trouble, sure, but there will be still others left,
e.g. he could still do:
add_fetch_refspec(remote, ...);// this doesn't update remote->fetch
for (i = 0; i < remote->fetch_refspec_nr; i++)
func(remote->fetch[i]);
and watch the array indexing blow up in the last iteration.
Or a non-hypothetical one: when I first tried to use remote_get() for
an earlier version of this patch, I ALLOC_GROW()-ed remote->fetch to
create room for the default refspec, because in struct remote not
**fetch_refspec but *fetch is listed right above
fetch_refspec_{nr,alloc}, being way past my bedtime may be my only
excuse... It didn't work :) [1]
To put your worries to rest we should eliminate remote->fetch_refspec
altogether and parse refspecs into remote->fetch right away, I'd
think. After all, that's what's used in most places anyway, and it
can be easily turned back to a single string where needed (I think in
only 3 places in builtin/remote.c).
[1] - Though in the end this could be considered beneficial, because
commits 53c5de29 (pickaxe: fix segfault with '-S<...>
--pickaxe-regex', 2017-03-18), 59210dd56 (tests: make the
'test_pause' helper work in non-verbose mode, 2017-03-18), and
4ecae3c8c (tests: create an interactive gdb session with the
'debug' helper, 2017-03-18) were all fallouts from the ensuing
debugging session :)
Re: [PATCH 0/3] update sha1dc
On Tue, Jun 6, 2017 at 8:12 AM, Ævar Arnfjörð Bjarmason wrote: > This updates sha1dc fixing the issue on Cygwin introduced in 2.13.1, > and hopefully not regressing elsewhere. Liam, it would be much > appreciated if you could test this on SPARC. > > As before the "sha1dc: update from upstream" patch is what should > fast-track to master/maint and be in 2.13.2, the other two are the > cooking submodule use, that's all unchanged aside from of course the > submodule pointing to the same upstream commit as the code import > itself does. > > Junio: There's a whitespace change to sha1.h that am warns about, but > which it applies anyway that you didn't apply from my previous > patch. I think it probably makes sense to just take upstream's > whitespace shenanigans as-is instead of seeing that diff every time we > update. I guess we could also send them a pull request... I would suggest the pull request. Also as to not make the mistake from before that I jump on the submodule bandwagon here: Patch 1 ought to go in its on series/patch, so with that out the way we have more time to consider the pros and cons of the rest of the series? Thanks, Stefan
Re: [BUG] Help > About Git Gui = crash
On Tue, Jun 6, 2017 at 10:34 AM, Konstantin Podsvirov wrote: > Reproduction: > - Start git gui > - Go to menu panel: Help > About Git Gui > > Output: > error: git-gui died of signal 11 > > Environment: > Debian 8 jessie amd64 KDE Care to also share the output of $ git gui --version $ git --version as I suspect this to come from git and git-gui not working well together.
Re: [PATCHv4 1/2] clone: respect additional configured fetch refspecs during initial fetch
On Tue, Jun 06, 2017 at 08:19:09PM +0200, SZEDER Gábor wrote:
> > if (!remote->fetch)
> > BUG("cannot add refspec to an unparsed remote");
> >
> > ?
>
> But as mentioned before, remote->fetch being NULL is not a bug in
> itself, it's a perfectly valid value even in a fully parsed remote
> when the remote has no fetch refspecs.
> Therefore, I think, the condition should instead be:
>
> remote->fetch_refspec_nr && !remote->fetch
Right, that would be a better check.
> We could even try to be extra helpful by checking this condition and
> calling parse_fetch_refspec() to initialize remote->fetch instead of
> BUG()ing out. However, that would mask the real issue, namely not
> using remote_get() to get the remote, so I don't actually think that's
> a good thing to do.
OK.
> To put your worries to rest we should eliminate remote->fetch_refspec
> altogether and parse refspecs into remote->fetch right away, I'd
> think. After all, that's what's used in most places anyway, and it
> can be easily turned back to a single string where needed (I think in
> only 3 places in builtin/remote.c).
I don't think we can parse right away without regressing the error
handling. If I have two remotes, one with a bogus refspec, like:
[remote "one"]
url = ...
fetch = refs/heads/*:refs/remotes/one/*
[remote "two"]
url = ...
fetch = ***bogus***
and I do:
git fetch one
then read_config() will grab the data for _both_ of them, but only call
remote_get() on the first one. If we parsed the refspecs during
read_config(), we'd parse the bogus remote.two.fetch and die().
I guess that's a minor case, but as far as I can tell that's the
motivation for the lazy parsing.
-Peff
Re: Feature request: Please add support to stash specific files
Hi Randall, I completely agree to what you are saying, but sometimes it just so happens that in the middle of a change, i feel like if some portion of the changes are fine I can commit them. Stashing some of the files and being able to check the compile/tests at this point would be a really awesome change. Stash supports a -p option to deal with this, it becomes cumbersome when the number of files are many. Maybe it is something which would be a good to have feature. People need not use it if they dont want to. Thanks Rajdeep On Tue, Jun 6, 2017 at 9:31 AM, Randall S. Becker wrote: > -Original Message- > On June 6, 2017 9:23 AM, rajdeep mondal wrote: >>Work around found in: >>https://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git >>Workaround is not very optimal. Please add this support to git. > > Instead of using stash as part of your normal process, consider using topic > branches instead. Before working, switch to a new topic branch. If you > forget, stash, switch, apply, then go forth. While on the topic branch, you > can use add and commit on a hunk or file basis to satisfy what appears to be > the requirement here. You can then merge the desired commits from your topic > branch into wherever you want to merge them either preserving the commit or > by squashing commits together. > > In my shop, stash is only used for the "I forgot to switch to a topic branch, > oops" process. I try to encourage people not to use it. I also discourage > squashed commits, but that's because I like knowing what's in my sausages 😊 > > Cheers, > Randall > > -- == Rajdeep ==
Re: [BUG?] gitlink without .gitmodules no longer fails recursive clone
On Tue, Jun 06, 2017 at 11:10:24AM -0700, Brandon Williams wrote: > > > This bisects to your bb62e0a99 (clone: teach --recurse-submodules to > > > optionally take a pathspec, 2017-03-17). That patch just sets > > > submodule.active by default, so I think the real issue is probably in > > > a086f921a (submodule: decouple url and submodule interest, 2017-03-17). > > > > It's a feature, not a bug, IMO. > > > > When starting out the journey to improve submodules, one of the major > > principle was to not interfere with gitlinks too much, as they are used in > > ways git cannot fathom (cf git-series storing patches in gitlink form). > > > > And building on that: You asked for recursing into *submodules*, not > > into *gitlinks*. And submodules in the new Git have stronger requirements > > w.r.t. the gitmodules file. (You have to tell us exactly how you want your > > submodule to be treated, and we do not want to half-ass guess around > > the shortcomings of a user not telling us about the submodule) > > Just for some background on the new behavior and how this functionality > changed: My series changed how 'submodule init' behaved if you have > 'submodule.active' set. Once set (like how clone --recurse does now) > when not provided any path to a submodule, a list of 'active' submodules > matching the 'submodule.active' pathspec will be initialized. One of > the requirements to be 'active' is to have an entry in the .gitmodules > file so gitlinks without an entry in the .gitmodules file will simply be > ignored now. OK, thanks for the explanation. I certainly agree that treating .gitmodules as the source of truth is consistent and easy to explain. I'll update my test to handle the new behavior (it's a regression test for how GitHub Pages handles some broken setups). -Peff
Re: What does this output of git supposed to mean ?
On Tue, Jun 06, 2017 at 01:43:55PM +0200, SZEDER Gábor wrote: > > An alternative ,with slightly less textual change, could be "Waiting for > > initial commit" > > > > We should consider orphan/unborn branches, too: > > git (master)$ git checkout --orphan newroot > Switched to a new branch 'newroot' > git (newroot +)$ git reset --hard > git (newroot #)$ git status > On branch newroot > > Initial commit > > nothing to commit (create/copy files and use "git add" to track) > > A purely textual change will not be sufficient, I'm afraid. Saying > "Repository is empty" right after 'git init' is fine, I like it. > However, on an unborn branch with empty index it would be just wrong. > > "Waiting for initial commit" is much better even in this case, but I > still don't like that "initial", though I can't say why, and don't > have any better suggestion either. Though users experienced enough to > create an empty unborn branch would probably not be confused by that. I agree. If the state we are describing is limited to the current branch, how about saying so? Like "Your current branch has no commits". -Peff
Re: [PATCH 2/3] sha1dc: optionally use sha1collisiondetection as a submodule
On Tue, Jun 6, 2017 at 8:12 AM, Ævar Arnfjörð Bjarmason wrote: > Add an option to use the sha1collisiondetection library from the > submodule in sha1collisiondetection/ instead of in the copy in the > sha1dc/ directory. > > This allows us to try out the submodule in sha1collisiondetection > without breaking the build for anyone who's not expecting them as we > work out any kinks. > > Signed-off-by: Ævar Arnfjörð Bjarmason Other projects using submodules sometimes have a .gitattributes entry to have .gitmodules not exported via git-archive. Do we want a similar thing? Speaking of attributes, I wonder if we want to specify the .gitmodules file to be text with unixy file endings: Having an entry .gitattributes eol=crlf to simulate a Windows environment doesn't harm submodule operation, which is good. I'll check if we have a test for that.
Re: [PATCH 0/3] update sha1dc
On Tue, Jun 6, 2017 at 8:23 PM, Stefan Beller wrote: > On Tue, Jun 6, 2017 at 8:12 AM, Ævar Arnfjörð Bjarmason > wrote: >> This updates sha1dc fixing the issue on Cygwin introduced in 2.13.1, >> and hopefully not regressing elsewhere. Liam, it would be much >> appreciated if you could test this on SPARC. >> >> As before the "sha1dc: update from upstream" patch is what should >> fast-track to master/maint and be in 2.13.2, the other two are the >> cooking submodule use, that's all unchanged aside from of course the >> submodule pointing to the same upstream commit as the code import >> itself does. >> >> Junio: There's a whitespace change to sha1.h that am warns about, but >> which it applies anyway that you didn't apply from my previous >> patch. I think it probably makes sense to just take upstream's >> whitespace shenanigans as-is instead of seeing that diff every time we >> update. I guess we could also send them a pull request... > > I would suggest the pull request. Looking at this again it's not a bug, just upstream choosing to indent a comment with spaces, not a bug. So it makes sense to just apply as-is so we don't have that diff with them / different sha1s on the files etc. > Also as to not make the mistake from before that I jump on the > submodule bandwagon here: > Patch 1 ought to go in its on series/patch, so with that out the way > we have more time to consider the pros and cons of the rest of > the series? Yes it makes perfect sense to just take the 1st patch here and make the submodule changes cook. This is just how I submitted it the last time and Junio took the 1st patch into a maint topic, so I figured I'd send it like this again.
Re: What does this output of git supposed to mean ?
On Tue, Jun 06, 2017 at 02:42:01PM -0400, Jeff King wrote: > > "Waiting for initial commit" is much better even in this case, but I > > still don't like that "initial", though I can't say why, and don't > > have any better suggestion either. Though users experienced enough to > > create an empty unborn branch would probably not be confused by that. > > I agree. If the state we are describing is limited to the current > branch, how about saying so? Like "Your current branch has no commits". Actually, something like "does not yet have any commits" might be better. There is a slight complication, though. There's similar text in "git status -sb", which shows: ## Initial commit on master Should that also change to use consistent terminology? If so, we need a phrasing short phrasing that matches (and the --porcelain and --porcelain=v2 formats of course would need to remain the same). -Peff
[PATCH] sha1dc: ignore indent-with-non-tab whitespace violations
On Tue, Jun 06, 2017 at 08:51:35PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jun 6, 2017 at 8:23 PM, Stefan Beller wrote: > > On Tue, Jun 6, 2017 at 8:12 AM, Ævar Arnfjörð Bjarmason > > wrote: > >> This updates sha1dc fixing the issue on Cygwin introduced in 2.13.1, > >> and hopefully not regressing elsewhere. Liam, it would be much > >> appreciated if you could test this on SPARC. > >> > >> As before the "sha1dc: update from upstream" patch is what should > >> fast-track to master/maint and be in 2.13.2, the other two are the > >> cooking submodule use, that's all unchanged aside from of course the > >> submodule pointing to the same upstream commit as the code import > >> itself does. > >> > >> Junio: There's a whitespace change to sha1.h that am warns about, but > >> which it applies anyway that you didn't apply from my previous > >> patch. I think it probably makes sense to just take upstream's > >> whitespace shenanigans as-is instead of seeing that diff every time we > >> update. I guess we could also send them a pull request... > > > > I would suggest the pull request. > > Looking at this again it's not a bug, just upstream choosing to indent > a comment with spaces, not a bug. > > So it makes sense to just apply as-is so we don't have that diff with > them / different sha1s on the files etc. Agreed. Maybe we'd also want this patch: -- >8 -- Subject: sha1dc: ignore indent-with-non-tab whitespace violations The upstream sha1dc code indents some lines with spaces. While this doesn't match Git's coding guidelines, it's better to leave this imported code untouched than to try to make it match our style. However, we can use .gitattributes to tell "diff --check" and "git am" not to bother us about it. Signed-off-by: Jeff King --- sha1dc/.gitattributes | 1 + 1 file changed, 1 insertion(+) create mode 100644 sha1dc/.gitattributes diff --git a/sha1dc/.gitattributes b/sha1dc/.gitattributes new file mode 100644 index 0..da53f4054 --- /dev/null +++ b/sha1dc/.gitattributes @@ -0,0 +1 @@ +* whitespace=-indent-with-non-tab -- 2.13.1.664.g1b5a21ec3
Re: [PATCH 2/3] sha1dc: optionally use sha1collisiondetection as a submodule
On Tue, Jun 6, 2017 at 8:48 PM, Stefan Beller wrote: > On Tue, Jun 6, 2017 at 8:12 AM, Ævar Arnfjörð Bjarmason > wrote: >> Add an option to use the sha1collisiondetection library from the >> submodule in sha1collisiondetection/ instead of in the copy in the >> sha1dc/ directory. >> >> This allows us to try out the submodule in sha1collisiondetection >> without breaking the build for anyone who's not expecting them as we >> work out any kinks. >> >> Signed-off-by: Ævar Arnfjörð Bjarmason > > Other projects using submodules sometimes have > a .gitattributes entry to have .gitmodules not exported > via git-archive. Do we want a similar thing? Right now we end up with an empty directory due to the issue you noted in https://public-inbox.org/git/cagz79kzc98cxa69qjmx2s_su6z1csgkgwzeqvwimraqc6+s...@mail.gmail.com/ It's probably best to have the .gitmodules file as some hint that something should be there. We also ship the other .git* files. > Speaking of attributes, I wonder if we want to specify > the .gitmodules file to be text with unixy file endings: > Having an entry > .gitattributes eol=crlf > to simulate a Windows environment doesn't harm > submodule operation, which is good. I'll check if we > have a test for that. I have no idea what that would do or why we'd have it, but I'm going to understand this as you looking into it :)
Re: [PATCH] sha1dc: ignore indent-with-non-tab whitespace violations
On Tue, Jun 6, 2017 at 9:01 PM, Jeff King wrote: > On Tue, Jun 06, 2017 at 08:51:35PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> On Tue, Jun 6, 2017 at 8:23 PM, Stefan Beller wrote: >> > On Tue, Jun 6, 2017 at 8:12 AM, Ævar Arnfjörð Bjarmason >> > wrote: >> >> This updates sha1dc fixing the issue on Cygwin introduced in 2.13.1, >> >> and hopefully not regressing elsewhere. Liam, it would be much >> >> appreciated if you could test this on SPARC. >> >> >> >> As before the "sha1dc: update from upstream" patch is what should >> >> fast-track to master/maint and be in 2.13.2, the other two are the >> >> cooking submodule use, that's all unchanged aside from of course the >> >> submodule pointing to the same upstream commit as the code import >> >> itself does. >> >> >> >> Junio: There's a whitespace change to sha1.h that am warns about, but >> >> which it applies anyway that you didn't apply from my previous >> >> patch. I think it probably makes sense to just take upstream's >> >> whitespace shenanigans as-is instead of seeing that diff every time we >> >> update. I guess we could also send them a pull request... >> > >> > I would suggest the pull request. >> >> Looking at this again it's not a bug, just upstream choosing to indent >> a comment with spaces, not a bug. >> >> So it makes sense to just apply as-is so we don't have that diff with >> them / different sha1s on the files etc. > > Agreed. Maybe we'd also want this patch: Great, that makes perfect sense for prepending to the series. > -- >8 -- > Subject: sha1dc: ignore indent-with-non-tab whitespace violations > > The upstream sha1dc code indents some lines with spaces. > While this doesn't match Git's coding guidelines, it's better > to leave this imported code untouched than to try to make it > match our style. However, we can use .gitattributes to tell > "diff --check" and "git am" not to bother us about it. > > Signed-off-by: Jeff King > --- > sha1dc/.gitattributes | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 sha1dc/.gitattributes > > diff --git a/sha1dc/.gitattributes b/sha1dc/.gitattributes > new file mode 100644 > index 0..da53f4054 > --- /dev/null > +++ b/sha1dc/.gitattributes > @@ -0,0 +1 @@ > +* whitespace=-indent-with-non-tab > -- > 2.13.1.664.g1b5a21ec3 >
Re: [PATCH] sha1dc: ignore indent-with-non-tab whitespace violations
> Subject: sha1dc: ignore indent-with-non-tab whitespace violations > > The upstream sha1dc code indents some lines with spaces. > While this doesn't match Git's coding guidelines, it's better > to leave this imported code untouched than to try to make it > match our style. However, we can use .gitattributes to tell > "diff --check" and "git am" not to bother us about it. > > Signed-off-by: Jeff King Reviewed-by: Stefan Beller > --- > sha1dc/.gitattributes | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 sha1dc/.gitattributes > > diff --git a/sha1dc/.gitattributes b/sha1dc/.gitattributes > new file mode 100644 > index 0..da53f4054 > --- /dev/null > +++ b/sha1dc/.gitattributes > @@ -0,0 +1 @@ > +* whitespace=-indent-with-non-tab > -- > 2.13.1.664.g1b5a21ec3 >
Re: [PATCH 2/3] sha1dc: optionally use sha1collisiondetection as a submodule
On Tue, Jun 6, 2017 at 12:03 PM, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jun 6, 2017 at 8:48 PM, Stefan Beller wrote: >> On Tue, Jun 6, 2017 at 8:12 AM, Ævar Arnfjörð Bjarmason >> wrote: >>> Add an option to use the sha1collisiondetection library from the >>> submodule in sha1collisiondetection/ instead of in the copy in the >>> sha1dc/ directory. >>> >>> This allows us to try out the submodule in sha1collisiondetection >>> without breaking the build for anyone who's not expecting them as we >>> work out any kinks. >>> >>> Signed-off-by: Ævar Arnfjörð Bjarmason >> >> Other projects using submodules sometimes have >> a .gitattributes entry to have .gitmodules not exported >> via git-archive. Do we want a similar thing? > > Right now we end up with an empty directory due to the issue you noted > in > https://public-inbox.org/git/cagz79kzc98cxa69qjmx2s_su6z1csgkgwzeqvwimraqc6+s...@mail.gmail.com/ > > It's probably best to have the .gitmodules file as some hint that > something should be there. We also ship the other .git* files. Ok, but then let's talk about the other .git* files, would we want to distribute these via tarballs? (I guess it is a minor thing if at all and nobody downloading a git tarball would be surprised by these metadata files or annoyed by them, so all is good?) > >> Speaking of attributes, I wonder if we want to specify >> the .gitmodules file to be text with unixy file endings: >> Having an entry >> .gitattributes eol=crlf >> to simulate a Windows environment doesn't harm >> submodule operation, which is good. I'll check if we >> have a test for that. > > I have no idea what that would do or why we'd have it, but I'm going > to understand this as you looking into it :) I looked briefly into it and it seems to be no problem just as config files on Windows are no problem. I just spoke up too quickly.
Re: [BUG] Help > About Git Gui = crash
06.06.2017, 21:25, "Stefan Beller" : > On Tue, Jun 6, 2017 at 10:34 AM, Konstantin Podsvirov > wrote: >> Reproduction: >> - Start git gui >> - Go to menu panel: Help > About Git Gui >> >> Output: >> error: git-gui died of signal 11 >> >> Environment: >> Debian 8 jessie amd64 KDE > > Care to also share the output of > > $ git gui --version git-gui version 0.19.0.2.g3decb8e > $ git --version git version 2.1.4 > > as I suspect this to come from git and git-gui not working well together. -- Regards, Konstantin Podsvirov
Re: [PATCH] t5313: make extended-table test more deterministic
> On 05 Jun 2017, at 21:15, Jeff King wrote:
>
> Commit a1283866b (t5313: test bounds-checks of
> corrupted/malicious pack/idx files, 2016-02-25) added a test
> that requires our corrupted pack index to have two objects.
> The entry for the first one remains untouched, but we
> corrupt the entry for second one. Since the index stores the
> entries in sha1-sorted order, this means that the test must
> make sure that the sha1 of the object we expect to be
> corrupted ("$object") sorts after the other placeholder
> object.
>
> That commit used the HEAD commit as the placeholder, but the
> script never calls test_tick. That means that the commit
> object (and thus its sha1) depends on the timestamp when the
> test script is run. This usually works in practice, because
> the sha1 of $object starts with "fff". The commit object
> will sort after that only 1 in 4096 times, but when it does
> the test will fail.
>
> One obvious solution is to add the test_tick call to get a
> deterministic commit sha1. But since we're relying on the
> sort order for the test to function, let's make that very
> explicit by just generating a second blob with a known sha1.
Works for me! Thanks for the explanation!
- Lars
>
> Reported-by: Lars Schneider
> Signed-off-by: Jeff King
> ---
> t/t5313-pack-bounds-checks.sh | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/t/t5313-pack-bounds-checks.sh b/t/t5313-pack-bounds-checks.sh
> index a8a587abc..9372508c9 100755
> --- a/t/t5313-pack-bounds-checks.sh
> +++ b/t/t5313-pack-bounds-checks.sh
> @@ -139,7 +139,13 @@ test_expect_success 'bogus offset into v2 extended
> table' '
> test_expect_success 'bogus offset inside v2 extended table' '
> # We need two objects here, so we can plausibly require
> # an extended table (if the first object were larger than 2^31).
> - do_pack "$object $(git rev-parse HEAD)" --index-version=2 &&
> + #
> + # Note that the value is important here. We want $object as
> + # the second entry in sorted-sha1 order. The sha1 of 1485 starts
> + # with "000", which sorts before that of $object (which starts
> + # with "fff").
> + second=$(echo 1485 | git hash-object -w --stdin) &&
> + do_pack "$object $second" --index-version=2 &&
>
> # We have to make extra room for the table, so we cannot
> # just munge in place as usual.
> --
> 2.13.1.662.g6e89c999d
Re: Feature request: Please add support to stash specific files
On Tue, Jun 06, 2017 at 02:38:08PM -0400, rajdeep mondal wrote: > Hi Randall, > > I completely agree to what you are saying, but sometimes it just so > happens that in the middle of a change, i feel like if some portion of > the changes are fine I can commit them. Stashing some of the files > and being able to check the compile/tests at this point would be a > really awesome change. > > Stash supports a -p option to deal with this, it becomes cumbersome > when the number of files are many. Maybe it is something which would > be a good to have feature. People need not use it if they dont want > to. Git 2.13.0 has that already. git stash -- file1 file2 Mike
Re: Feature request: Please add support to stash specific files
Thanks Mike. On Tue, Jun 6, 2017 at 5:03 PM, Mike Hommey wrote: > On Tue, Jun 06, 2017 at 02:38:08PM -0400, rajdeep mondal wrote: >> Hi Randall, >> >> I completely agree to what you are saying, but sometimes it just so >> happens that in the middle of a change, i feel like if some portion of >> the changes are fine I can commit them. Stashing some of the files >> and being able to check the compile/tests at this point would be a >> really awesome change. >> >> Stash supports a -p option to deal with this, it becomes cumbersome >> when the number of files are many. Maybe it is something which would >> be a good to have feature. People need not use it if they dont want >> to. > > Git 2.13.0 has that already. > > git stash -- file1 file2 > > Mike -- == Rajdeep ==
Re: What does this output of git supposed to mean ?
From: "Kaartic Sivaraam" On Tue, 2017-06-06 at 20:52 +0900, Junio C Hamano wrote: "Waiting for the initial commit", or "No commits yet", can be explained to describe the state of the current branch (not the state of the repository), and it is correct that we do not have any commit on the branch, and the branch is waiting for the initial commit. Looks descriptive to me too. Just for the note, I wouldn't have asked this question if `git status` showed a message like this. Maybe have a try at a patch to update the text? See the git/Documentation/SubmittingPatches for guidance. -- Regards, Kaartic Sivaraam
Re: What's cooking in git.git (Jun 2017, #03; Mon, 5)
On Tue, Jun 6, 2017 at 2:50 AM, Michael Haggerty wrote: > On Mon, Jun 5, 2017 at 8:23 PM, Stefan Beller wrote: >> >> > [...] >> > "git diff" has been taught to optionally paint new lines that are >> > the same as deleted lines elsewhere differently from genuinely new >> > lines. >> > >> > Are we happy with these changes? > > > I've been studiously ignoring this patch series due to lack of bandwidth. > >> [...] >> Things to come, but not in this series as they are more advanced: >> >> Discuss if a block/line needs a minimum requirement. >> >> When doing reviews with this series, a couple of lines such >> as "\t\t}" were marked as a moved, which is not wrong as they >> really occurred in the text with opposing sign. >> But it was annoying as it drew my attention to just closing >> braces, which IMO is not the point of code review. >> >> To solve this issue I had the idea of a "minimum requirement", e.g. >> * at least 3 consecutive lines or >> * at least one line with at least 3 non-ws characters or >> * compute the entropy of a given moved block and if it is too low, do >> not mark it up. > > Shooting from the hip here... > > It seems obvious that for a line to be marked as moved, a minimum > requirement is that > > 1. The line appears as both "+" and "-". > > That doesn't seem strong enough evidence though, and if that is the > only criterion, I would expect a lot of boilerplate lines like "\t\t}" > to be marked as moved. It seems like a lot of noise could be > eliminated by *also* requiring that > > 2a. The line doesn't appear elsewhere in the file(s) concerned. > > Rule (2a) would probably get rid of most boilerplate lines without > having to try to measure entropy. > > Maybe you are already using both criteria? I didn't see it in a quick > perusal of the code. > > OTOH, it would be silly to refuse to mark lines like "\t\t}" as moved > *only* because they appear elsewhere in the file(s). If you did so, > you would have gaps of supposedly non-moved lines in the middle of > moved blocks. This suggests marking as moved lines matching (1) and > (2a) but also lines matching (1) and the following: > > 2b. The line is adjacent to to another line that is thought to have > moved from the same old location to the same new location. > > Rule (2b) would be applied recursively, with the net effect being that > any line satisfying (1) and (2a) is allowed to carry along any > neighboring lines within the same "+"/"-" block even if they are not > unique. > > Michael This sounds reasonable to me, though I'm not sure how easy it is to implement. Thanks, Jake
Re: New Order
Dear Sir, Have a nice day! We are interested in purchasing your products.Send your latest catalog, also inform me about the Minimum order quantity, Delivery time or FOB, and payment terms warranty. Thanks and Best Regards, Mr.Marco Plujm. Phone: (+1) 703-684-5885 Fax: (+1) 703-684-0644 Washington, DC 20052 United State
Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output
Hi Jonathan, On Fri, 2 Jun 2017, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > On Thu, 1 Jun 2017, Stefan Beller wrote: > > >> We had a discussion off list how much of the test suite is in bad shape, > >> and "$ git grep ^index" points out a lot of places as well. > > > > Maybe we should call out a specific month (or even a longer period) during > > which we try to push toward that new hash function, and focus more on > > those tasks (and on critical bug fixes, if any) than anything else. > > Thanks for offering. ;-) Undoubtedly my lack of command of the English language is to blame for this misunderstanding. By no means did I try to indicate that I am ready to accept the responsibility of working toward a new hash dumped on me. What I wanted to suggest instead was that the current direction looks very unfocused to me, and that I do not see anything going forward in a coherent manner. Hence my suggestion to make it public known that a certain time period would be dedicated (and contributions would be highly encouraged) to work on replacing SHA-1 by something else. But: 1) this cannot be a one-person effort, it is too large 2) it cannot even be as uncoordinated an effort as it is now, because that leads only to bikeshedding instead of progress 3) the only person who could make that call is Junio 4) we still have the problem that there is no cryptography expert among those who in the Git project are listened to > How did you get the impression that their opinion had no impact? We have > been getting feedback about the choice of hash function both on and off > list from a variety of people, some indisputably security experts. > Sometimes the best one can do is to just listen. I did get the impression by talking at length to a cryptography expert who successfully resisted any suggestions to get involved in the Git mailing list. There were also accounts floating around on Twitter that a certain cryptography expert who dared to mention already back in 2005 how dangerous it would be to hardcode SHA-1 into Git was essentially shown the finger, and I cannot fault him for essentially saying "I told you so" publicly. In my mind, it would have made sense to ask well-respected cryptographers about their opinions and then try to figure out a consensus among them (as opposed to what I saw so far, a lot of enthusastic talk by developers with little standing in the cryptography community, mostly revolving around hash size and speed as opposed to security). And then try to implement that consensus in Git. Given my recent success rate with SHA-1 related concerns, I am unfortunately not the person who can bring that about. But maybe you are. Ciao, Dscho
Re: How to avoid "Please tell me who you are..."?
Jeffrey Walton writes: > On Fri, Jun 2, 2017 at 2:30 AM, Davide Fiorentino > wrote: >> Is there a reason why you don't want or can't set those details? > > Well, they don't exist so there's nothing to set. > > The machine below its a CubieBoard used for testing. I remote into it > with test@. As a matter of policy, no check-ins occur on it. Other > than the password database and authroized_keys file, there is no > information on it to be lost or stolen. One thing I forgot to ask you. Are you reporting "I have used this exact procedure to set up a test machine in the past and did not have this problem, but with newer Git I get this message and cannot cherry-pick or tag or do anything"? Or is this something you noticed with a version of Git you happened to have? I am trying to make sure this is not reporting a regression, as I am not aware of any recent change that wanted to make the "unconfigured user" detection stricter than before. Thanks.
Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output
Hi, Johannes Schindelin wrote: > On Fri, 2 Jun 2017, Jonathan Nieder wrote: >> Johannes Schindelin wrote: >>> Maybe we should call out a specific month (or even a longer period) during >>> which we try to push toward that new hash function, and focus more on >>> those tasks (and on critical bug fixes, if any) than anything else. >> >> Thanks for offering. ;-) > > Undoubtedly my lack of command of the English language is to blame for > this misunderstanding. > > By no means did I try to indicate that I am ready to accept the > responsibility of working toward a new hash dumped on me. It was a joke. More seriously, I do appreciate your questions to get this discussion going. [...] > 3) the only person who could make that call is Junio I strongly disagree with this. > 4) we still have the problem that there is no cryptography expert among > those who in the Git project are listened to *shrug* I still don't know what you are suggesting here. Are you saying we should find a cryptography expert to pay? Or do you have other specific suggestions of how to attract them? >> How did you get the impression that their opinion had no impact? We have >> been getting feedback about the choice of hash function both on and off >> list from a variety of people, some indisputably security experts. >> Sometimes the best one can do is to just listen. > > I did get the impression by talking at length to a cryptography expert who > successfully resisted any suggestions to get involved in the Git mailing > list. I know of other potential Git contributors that have resisted getting involved in the Git mailing list, too. I still don't know what you are suggesting here. Forgive me for being dense. > There were also accounts floating around on Twitter that a certain > cryptography expert who dared to mention already back in 2005 how > dangerous it would be to hardcode SHA-1 into Git was essentially shown the > finger, and I cannot fault him for essentially saying "I told you so" > publicly. I think there is a concrete suggestion embedded here: when discussions go in an unproductive direction, my usual practice has been to keep away from them. This means that to a casual observer there can appear to be a consensus that doesn't really exist. We need to do better than that: when a prominent contributor like Linus and people newer to the project are emphatically dismissing the security impact of using a broken hash function, others in the project need to speak up to make it clear that those are not the actual opinions of the project. To put it another way: "The standard you walk past is the standard you accept". I have failed at this. It is a very hard problem to solve, but it is worth solving. > In my mind, it would have made sense to ask well-respected cryptographers > about their opinions and then try to figure out a consensus among them (as > opposed to what I saw so far, a lot of enthusastic talk by developers with > little standing in the cryptography community, mostly revolving around > hash size and speed as opposed to security). And then try to implement > that consensus in Git. Given my recent success rate with SHA-1 related > concerns, I am unfortunately not the person who can bring that about. > > But maybe you are. I think you are being a bit dismissive of both the work done so far and the value of your own work. I am happy to solicit more input from security researchers, though, and your suggestion to do so is good advice. Thanks and hope that helps, Jonathan
Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output
On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin wrote: >> Thanks for offering. ;-) > > Undoubtedly my lack of command of the English language is to blame for > this misunderstanding. Sometimes it is best to not be a native speaker, just fluent enough to get by. :) > What I wanted to suggest instead was that the current direction looks very > unfocused to me That is unfortunate but reality of being a *real* community project. Neither you nor me (nor Junio) can command people to do things. The best we can do is reject an idea going off. >, and that I do not see anything going forward in a > coherent manner. But is this bad? > 1) this cannot be a one-person effort, it is too large I agree. But there are efforts by multiple people. See Brians series (lots of different reviewers), also Brandon picked up parts of it (origin/bw/object-id). Or the design that was discussed on list, which was lots of people participation. > > 2) it cannot even be as uncoordinated an effort as it is now, because that > leads only to bikeshedding instead of progress Jonathan presented a list of things, that can be done in parallel in an uncoordinated effort, because that is how the project works. (C.f. he mentioned "rogue agents") > 3) the only person who could make that call is Junio Occasionally I think the same, but in fact it is not true. As said above, Junio has strong veto power for things going off rails, but in his role as a maintainer he does not coordinate people. (He occasionally asks them to coordinate between themselves, though) > > 4) we still have the problem that there is no cryptography expert among > those who in the Git project are listened to I can assure you that Jonathan listened to crypto experts. It just did not happen on the mailing list, which is sad regarding openness and transparency. 5. The timeline you seem to favor would be really great for people working on Git at $BIG_CORP, as big corps usually plan things by the quarter. So maybe by having a timeline (known in advance of the quarter) can convince managers easier. > >> How did you get the impression that their opinion had no impact? We have >> been getting feedback about the choice of hash function both on and off >> list from a variety of people, some indisputably security experts. >> Sometimes the best one can do is to just listen. > > I did get the impression by talking at length to a cryptography expert who > successfully resisted any suggestions to get involved in the Git mailing > list. > > There were also accounts floating around on Twitter that a certain > cryptography expert who dared to mention already back in 2005 how > dangerous it would be to hardcode SHA-1 into Git was essentially shown the > finger, and I cannot fault him for essentially saying "I told you so" > publicly. Heh. The community between 2005 and now has changed. (I was not there for example. ;-) ) So let's hope the community changes for the better. > In my mind, it would have made sense to ask well-respected cryptographers > about their opinions and then try to figure out a consensus among them (as > opposed to what I saw so far, a lot of enthusastic talk by developers with > little standing in the cryptography community, mostly revolving around > hash size and speed as opposed to security). And then try to implement > that consensus in Git. Sounds good to me. That is why I personally think point (4) from Jonathans list above over-emphasizes performance/size over security. On the other hand if we find a smart way now, then this hash function transition will open the road to switching the hash function down the road once again with less or even no penalty if we make mistakes in choosing yet another bad hash function now. > Given my recent success rate with SHA-1 related > concerns, I am unfortunately not the person who can bring that about. > > But maybe you are. > > Ciao, > Dscho Thanks for bringing the discussion back to life, Stefan
Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output
Stefan Beller wrote: > On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin > wrote: >> In my mind, it would have made sense to ask well-respected cryptographers >> about their opinions and then try to figure out a consensus among them (as >> opposed to what I saw so far, a lot of enthusastic talk by developers with >> little standing in the cryptography community, mostly revolving around >> hash size and speed as opposed to security). And then try to implement >> that consensus in Git. > > Sounds good to me. That is why I personally think point (4) from > Jonathans list above over-emphasizes performance/size over security. The very least the only kind of replies my example task (4) led to were of this kind, so you can get a clear sense of whether the community values performance over security. :) I happen to think that performance and security both matter and are related (since if performance regresses enough, then people end up using the faster but insecure thing). This has shown up in the history of SSL, for example. But I am very happy to see people focusing more on the security properties than the performance properties --- that is a correct prioritization. Jonathan
Re: [PATCH] docs: suggest "Helped-by" rather than "Thanks-to"
Adam Dinwoodie writes: > On Mon, Jun 05, 2017 at 11:42:31AM -0700, Stefan Beller wrote: >> So I was wondering if there is a command that shows all trailers? >> Similar to a "shortlog -sne" I would want to have a list of all trailers. >> This is because there might be an even more popular trailer than >> "Helped-by", but we would not know when using the hack above. >> >> While I do not think so, it would sure be interesting to have a list >> of all these trailers available. > > I just did a quick search with the following knocked-together command: > > git log --remotes --format=format:%B | sed -rn 's/^([A-Za-z0-9-]+): .* > <.*@.*>.*/\1/p' | sort | uniq -c | sort -nr > > The top 10 such tags according to this (which is coincidentally the same > list as the list of all tags used more than 100 times), with > frequencies, are: > > 61535 Signed-off-by >1641 Acked-by > 984 Reviewed-by > 673 Helped-by > 497 Reported-by > 180 Cc > 174 Suggested-by > 159 Tested-by > 158 Mentored-by > 128 Noticed-by > > As you might expect, there are a number of entertaining ones that have > only been used once or twice, such as "Looks-fine-to-me-by", > "Worriedly-Acked-by", "More-Spots-Found-By", "Looks-right-to-me-by", > "Hopefully-signed-off-by"... Thanks for an interesting list. Your replacing (totally unconventional) Thanks-to with more common Helped-by is certainly an improvement, but I wonder if we should encourage people to be "original" in this area by having that "You can also invent" paragraph in the first place.
Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output
On Tue, Jun 6, 2017 at 6:45 PM, Stefan Beller wrote: > On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin > wrote: >> >> 4) we still have the problem that there is no cryptography expert among >> those who in the Git project are listened to > > I can assure you that Jonathan listened to crypto experts. It just did not > happen on the mailing list, which is sad regarding openness and transparency. In the interest of openness and transparency, perhaps a blue doc should be put together to outline and document the hash function that succeeds SHA1, and the rationales for doing so? It would, ideally, cite (preferably by including, and not just linking to) any discussions with crypto experts that have chimed in off-list (given said experts' consent for any such communication to be publicized, naturally). If I'm not mistaken, the only such doc behind the transition right now is the Git hash function transition document, which covers the technical barriers to replacing SHA1, but not why we might choose X to replace SHA1.
Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output
Jonathan Nieder writes: >> 3) the only person who could make that call is Junio > > I strongly disagree with this. If it helps, I _can_ make any set of declarations to make it sound more official, e.g. (the remainder of) June is the "make sure our tests are ready" month where we try to eradiate uchar[20] by advancing the object-id effort, replace EMPTY_TREE_SHA1_HEX and friends with EMPTY_TREE_OID_HEX, add a build-time configuration that allows us to build a Git binary that uses a phony hash e.g. ~sha1 truncated to 16 bytes, and build Git with such a configuration and then run tests, and we concentrate on this effort without adding new things until we make the tests pass. And make similar declarations for the remainder of the year. But the actual input for formulating what each step does and the timeline we aim for needs to come from the list wisdom; it won't have much impact if the project's official declaration is not followed-thru, and a unilateral declaration that is pulled out of thin-air likely will not be. > I am happy to solicit more input from security researchers, though, > and your suggestion to do so is good advice. One good thing is that we can prepare the framework to adopt a new hash before knowing what the exact hash function is; crypto-minded folks can work on the hash selection in parallel without waiting for the framework to become ready. And I do agree with Dscho that having crypto experts would be very helpful for the latter.
[PATCH] t4005: modernize style and drop hard coded sha1
Use modern style in the test t4005. Remove hard coded sha1 values. Combine test prep work and the actual test. Rename the first test to contain the word "setup". Signed-off-by: Stefan Beller --- Junio wrote: > If it helps, I _can_ make any set of declarations to make it sound > more official, e.g. (the remainder of) June is the "make sure our > tests are ready" If it helps, I can write code for that. :) Do get a good grasp on which tests need to be fixed, I changed the seed value for the sha1 computation and then run the test suite. There are a lot of tests passing for this, but also quite a few failing. Then I picked t4005 randomly to start with. This patch works even with a crippled hash function as we use hash-object to get the object id. Thanks, Stefan t/t4005-diff-rename-2.sh | 95 ++-- 1 file changed, 43 insertions(+), 52 deletions(-) diff --git a/t/t4005-diff-rename-2.sh b/t/t4005-diff-rename-2.sh index 135addbfbd..f542d2929d 100755 --- a/t/t4005-diff-rename-2.sh +++ b/t/t4005-diff-rename-2.sh @@ -3,84 +3,75 @@ # Copyright (c) 2005 Junio C Hamano # -test_description='Same rename detection as t4003 but testing diff-raw. +test_description='Same rename detection as t4003 but testing diff-raw.' -' . ./test-lib.sh . "$TEST_DIRECTORY"/diff-lib.sh ;# test-lib chdir's into trash -test_expect_success \ -'prepare reference tree' \ -'cat "$TEST_DIRECTORY"/diff-lib/COPYING >COPYING && - echo frotz >rezrov && -git update-index --add COPYING rezrov && -tree=$(git write-tree) && -echo $tree' - -test_expect_success \ -'prepare work tree' \ -'sed -e 's/HOWEVER/However/' COPYING.1 && -sed -e 's/GPL/G.P.L/g' COPYING.2 && -rm -f COPYING && -git update-index --add --remove COPYING COPYING.?' +test_expect_success 'setup reference tree' ' + cat "$TEST_DIRECTORY"/diff-lib/COPYING >COPYING && + echo frotz >rezrov && + git update-index --add COPYING rezrov && + tree=$(git write-tree) && + echo $tree && + sed -e 's/HOWEVER/However/' COPYING.1 && + sed -e 's/GPL/G.P.L/g' COPYING.2 && + origoid=$(git hash-object COPYING) && + oid1=$(git hash-object COPYING.1) && + oid2=$(git hash-object COPYING.2) +' + # tree has COPYING and rezrov. work tree has COPYING.1 and COPYING.2, # both are slightly edited, and unchanged rezrov. We say COPYING.1 # and COPYING.2 are based on COPYING, and do not say anything about # rezrov. -git diff-index -C $tree >current - -cat >expected <<\EOF -:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0603b3238a076dc6c8022aedc6648fa523a17178 C1234 COPYING COPYING.1 -:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 06c67961bbaed34a127f76d261f4c0bf73eda471 R1234 COPYING COPYING.2 -EOF +test_expect_success 'validate output from rename/copy detection (#1)' ' + rm -f COPYING && + git update-index --add --remove COPYING COPYING.? && -test_expect_success \ -'validate output from rename/copy detection (#1)' \ -'compare_diff_raw current expected' + cat <<-EOF >expected && + :100644 100644 $origoid $oid1 C1234 COPYING COPYING.1 + :100644 100644 $origoid $oid2 R1234 COPYING COPYING.2 + EOF + git diff-index -C $tree >current && + compare_diff_raw expected current +' - -test_expect_success \ -'prepare work tree again' \ -'mv COPYING.2 COPYING && - git update-index --add --remove COPYING COPYING.1 COPYING.2' - # tree has COPYING and rezrov. work tree has COPYING and COPYING.1, # both are slightly edited, and unchanged rezrov. We say COPYING.1 # is based on COPYING and COPYING is still there, and do not say anything # about rezrov. -git diff-index -C $tree >current -cat >expected <<\EOF -:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 06c67961bbaed34a127f76d261f4c0bf73eda471 M COPYING -:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0603b3238a076dc6c8022aedc6648fa523a17178 C1234 COPYING COPYING.1 -EOF +test_expect_success 'validate output from rename/copy detection (#2)' ' + mv COPYING.2 COPYING && + git update-index --add --remove COPYING COPYING.1 COPYING.2 && -test_expect_success \ -'validate output from rename/copy detection (#2)' \ -'compare_diff_raw current expected' + cat <<-EOF >expected && + :100644 100644 $origoid $oid2 M COPYING + :100644 100644 $origoid $oid1 C1234 COPYING COPYING.1 + EOF + git diff-index -C $tree >current && + compare_diff_raw current expected +' - # tree has COPYING and rezrov. work tree has the same COPYING and # copy-edited COPYING.1, and unchanged rezrov. We should not say # anything about rezrov or COPYING, since the revised again d
[PATCH] pathspec: die on empty strings as pathspec
An empty string as a pathspec element matches all paths. A buggy
script, however, could accidentally assign an empty string to a
variable that then gets passed to a Git command invocation, e.g.:
path=... compute a path to be removed in $path ...
git rm -r "$path"
which would unintentionally remove all paths in the current
directory.
The fix for this issue comprises of two steps. Step 1, which warns
that empty strings as pathspecs will become invalid, has already
been implemented in commit d426430 ("pathspec: warn on empty strings
as pathspec", 2016-06-22).
This patch is step 2. It removes the warning and throws an error
instead.
Signed-off-by: Emily Xie
Reported-by: David Turner
---
pathspec.c | 10 --
t/t3600-rm.sh | 5 ++---
t/t3700-add.sh | 5 ++---
3 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/pathspec.c b/pathspec.c
index 50f76ff..65e18b1 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -605,7 +605,7 @@ void parse_pathspec(struct pathspec *pathspec,
{
struct pathspec_item *item;
const char *entry = argv ? *argv : NULL;
- int i, n, prefixlen, warn_empty_string, nr_exclude = 0;
+ int i, n, prefixlen, nr_exclude = 0;
memset(pathspec, 0, sizeof(*pathspec));
@@ -638,12 +638,10 @@ void parse_pathspec(struct pathspec *pathspec,
}
n = 0;
- warn_empty_string = 1;
while (argv[n]) {
- if (*argv[n] == '\0' && warn_empty_string) {
- warning(_("empty strings as pathspecs will be made
invalid in upcoming releases. "
- "please use . instead if you meant to match
all paths"));
- warn_empty_string = 0;
+ if (*argv[n] == '\0') {
+ die("empty string is not a valid pathspec. "
+ "please use . instead if you meant to match
all paths");
}
n++;
}
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 5f9913b..c787eac 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -858,9 +858,8 @@ test_expect_success 'rm files with two different errors' '
test_i18ncmp expect actual
'
-test_expect_success 'rm empty string should invoke warning' '
- git rm -rf "" 2>output &&
- test_i18ngrep "warning: empty strings" output
+test_expect_success 'rm empty string should fail' '
+ test_must_fail git rm -rf ""
'
test_done
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index f3a4b4a..40a0d2b 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -331,9 +331,8 @@ test_expect_success 'git add --dry-run --ignore-missing of
non-existing file out
test_i18ncmp expect.err actual.err
'
-test_expect_success 'git add empty string should invoke warning' '
- git add "" 2>output &&
- test_i18ngrep "warning: empty strings" output
+test_expect_success 'git add empty string should fail' '
+ test_must_fail git add ""
'
test_expect_success 'git add --chmod=[+-]x stages correctly' '
--
2.8.4
send-email: Net::SMTP::SSL failure
This is configured to send via a gmail account git send-email --to-cover --cc-cover I See Attempt to reload IO/Socket/SSL.pm aborted. Compilation failed in require at /usr/share/perl5/vendor_perl/Net/SMTP/SSL.pm line 6. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/Net/SMTP/SSL.pm line 6. Compilation failed in require at /usr/lib/git-core/git-send-email line 1386. fatal: 'send-email' appears to be a git command, but we were not able to execute it. Maybe git-send-email is broken? Net/SMTP/SSL.pm v1.04 perl v5.26.0 Seen in git 2.11.1, 2.12.2, 2.13.0, 2.13.1 on Arch Linux
