On Mon, Sep 23, 2019 at 09:16:26PM +0200, Johannes Sixt wrote:
> Am 23.09.19 um 10:37 schrieb SZEDER Gábor:
> > On Sun, Sep 22, 2019 at 11:01:26PM +0200, Johannes Sixt wrote:
> >> Huh? For signed cutoff and positive CUTOFF_DATE_SLOP,
> >> cutoff - CUTOFF_DATE_SLOP < cutoff is ALWAYS true. Signed in
When 'git name-rev' is invoked with commit-ish parameters, it tries to
save some work, and doesn't visit commits older than the committer
date of the oldest given commit minus a one day worth of slop. Since
our 'timestamp_t' is an unsigned type, this leads to a timestamp
underflow when the committ
I have information for you. Get back to me urgently
On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
> We've never had a formally written Code of Conduct document. Though it
> has been discussed off and on over the years, for the most part the
> behavior on the mailing list has been good enough that nobody felt the
> need to push one forwa
On Dienstag, 24. September 2019 00:24:15 CEST Jeff King wrote:
> > On the other hand, considering the already existing --from argument and
> > "format.from" config option:
> > https://git-scm.com/docs/git-config#Documentation/git-config.txt-formatfro
> > m
> >
> > Wouldn't it make sense to just dr
When we ran `make hdr-check`, we got the following warning on Arch Linux:
pack-bitmap.h:20:19: error: ‘BITMAP_IDX_SIGNATURE’ defined but not used
[-Werror=unused-const-variable=]
20 | static const char BITMAP_IDX_SIGNATURE[] = {'B', 'I', 'T', 'M'};
|
On 24.09.2019 5:46, Torsten Bögershausen wrote:
Out of curiosity:
What made the test fail, and does it pass noe ?
It failed to a bug in Windows Debug build, which caused iconv() to fail
in most cases, see:
https://public-inbox.org/git/pull.348.git.gitgitgad...@gmail.com/
How about the followi
On 24.09.2019 6:06, Torsten Bögershausen wrote:
Would this make more sense:
After I discovered that UTF-16-LE-BOM test was bugged,
I decided that better tests are required
OK
> Looking at the other test cases, should utf-8 be written as UTF-8
> for consistency ?
OK
> General remark:
> Do we
Hi
I am confused, I just pulled
but git log --graph --decorate
did not show all commits,
Only
git log --graph --decorate --all
and from the emails I received the commits shown by --all
Should be on a new branch.
I confess I am a mercurial user not a git user,
What is the reason for
On 24.09.2019 8:21, Johannes Sixt wrote:
What are we testing here? Is there some back-and-forth conversion going
on, and are we testing that the conversion happens at all, or that the
correct conversion/encoding is picked, or that the conversion that is
finally chosen is correct? Why does it help
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
From: Alexandr Miloslavskiy
According to its name, the test is designed for UTF-16-LE-BOM.
However, possibly due to copy&paste oversight, it was using UTF-32.
While the test succeeds (extra \000\000 are interpreted as NUL),
I myself had an unrelated problem which caused the test to fail.
When an
From: Alexandr Miloslavskiy
After I discovered that UTF-16-LE-BOM test was bugged, I decided that
better tests are required. Possibly the best option here is to compare
git results against hardcoded ground truth.
The new tests also cover more interesting chars where (ANSI != UTF-8).
Signed-off-
Hello,
We wish to retain your service as an intermediary representative on a contract
basis.If interested please advise for contract
info.
Manager.
On 9/24/2019 2:44 AM, Jeff King wrote:
> We've never had a formally written Code of Conduct document. Though it
> has been discussed off and on over the years, for the most part the
> behavior on the mailing list has been good enough that nobody felt the
> need to push one forward.
>
> However, ev
On 23/09/19 09:35PM, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 18 Sep 2019, Junio C Hamano wrote:
>
> > We have a new maintainer for git-gui now. Thanks Pratyush for
> > volunteering.
>
> Excellent!
>
> I opened PRs at https://github.com/prati0100/git-gui/pulls. Pratyush, do
> you accept co
Hi Gábor,
On Tue, 24 Sep 2019, SZEDER Gábor wrote:
> On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
> > We've never had a formally written Code of Conduct document. Though it
> > has been discussed off and on over the years, for the most part the
> > behavior on the mailing list has b
Hallo liebe Hoffnung, Sie haben meine Nachricht erhalten, bitte
Ich brauche eine sofortige Antwort
danke
michelle
On 19/09/19 12:11PM, Denton Liu wrote:
> On Fri, Sep 20, 2019 at 12:33:59AM +0530, Pratyush Yadav wrote:
> > On 19/09/19 11:47AM, Denton Liu wrote:
> > > For the record, you could do a
> > >
> > > git cherry-pick -Xsubtree=git-gui 00ddc9d13c 7560f547e6
> > >
> > > to bring them over instead of
Hi Peff
On 24/09/2019 07:44, Jeff King wrote:
We've never had a formally written Code of Conduct document. Though it
has been discussed off and on over the years, for the most part the
behavior on the mailing list has been good enough that nobody felt the
need to push one forward.
However, even
Johannes, would you please review?
Hi Peff,
On Mon, 23 Sep 2019, Jeff King wrote:
> On Tue, Sep 17, 2019 at 01:23:18PM +0200, Johannes Schindelin wrote:
>
> > The only slightly challenging aspect might be that `merge-one-file` is
> > actually not a merge strategy, but it is used as helper to be passed to
> > `git merge-index` via
Hi Peff,
On Mon, 23 Sep 2019, Jeff King wrote:
> On Mon, Sep 23, 2019 at 02:47:23PM +0200, Johannes Schindelin wrote:
>
> > The evaluation of the lazy prereq is indeed not different between Bash
> > or dash. It is nevertheless quite disruptive in the trace of a test
> > script, especially when it
Hi Gábor
On 24/09/2019 10:01, SZEDER Gábor wrote:
On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
[...]
After some poking around at various CoC options, this one seemed like
the best fit to me. But I'm open to suggestions or more discussion. It
seems to me that the important piece i
On Tue, Sep 24, 2019 at 04:25:45PM +0200, Johannes Schindelin wrote:
> > I think it could make sense for merge-index to be able to directly run
> > the merge-one-file code[1]. But I think we'd want to keep its ability to
> > run an arbitrary script, and for people to call merge-one-file
> > separa
On Tue, Sep 24, 2019 at 03:20:42PM +0200, Johannes Schindelin wrote:
> > If diversity and inclusion of other cultures is indeed a priority,
> > then we should carefully consider that some potential contributors
> > will rather choose not to contribute because of a CoC like this.
>
> Let me be blu
On Tue, Sep 24, 2019 at 08:13:27AM -0400, Derrick Stolee wrote:
> > I did find this nice set of guidelines in an old discussion:
> >
> >
> > https://github.com/mhagger/git/commit/c6e6196be8fab3d48b12c4e42eceae6937538dee
>
> While this document has good information, most of it would be better
On 9/24/2019 2:44 AM, Jeff King wrote:
>
> If people are on board with this direction, it might be fun to pick up a
> bunch of "Acked-by" trailers from people in the community who agree with
> it. It might give it more weight if many members have publicly endorsed
> it.
>
> I've cc'd g...@sfconse
Am 23.09.19 um 22:47 schrieb SZEDER Gábor:
> On Mon, Sep 23, 2019 at 09:55:11PM +0200, René Scharfe wrote:
>> -- >8 --
>> Subject: [PATCH] name-rev: use FLEX_ARRAY for tip_name in struct rev_name
>>
>> Give each rev_name its very own tip_name string. This simplifies memory
>> ownership, as callers
Hi all,
Deb here from Git's fiscal home. Let us know if you need any advice or
help finding a professional consultant to take a look at the Code of
Conduct document for you. I'm also happy to perosanlly take a look at
any draft(s).
Best,
Deb
On Tue, 2019-09-24 at 12:53 -0400, Garima Singh wrote
> On Mon, Sep 23, 2019 at 01:38:54PM -0700, Jonathan Tan wrote:
>
> > I didn't have any concrete ideas so I didn't include those, but some
> > unrefined ideas:
>
> One risk to a mentoring project like this is that the intern does a good
> job of steps 1-5, and then in step 6 we realize that the w
On 9/22/2019 11:17 PM, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm working in an unusual setup on WIndows. I need to 'git clone' over
> SSH, but a third party program has to handle the tunnel. It happens by
> using this git configuration:
>
> git config --global core.sshcommand "tunnel.exe .
On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
> We've never had a formally written Code of Conduct document. Though it
> has been discussed off and on over the years, for the most part the
> behavior on the mailing list has been good enough that nobody felt the
> need to push one forwa
> If people are on board with this direction, it might be fun to pick up a
> bunch of "Acked-by" trailers from people in the community who agree with
> it. It might give it more weight if many members have publicly endorsed
> it.
Thanks for starting this. I think Peff has stated better what I woul
On 09/24, Jeff King wrote:
> We've never had a formally written Code of Conduct document. Though it
> has been discussed off and on over the years, for the most part the
> behavior on the mailing list has been good enough that nobody felt the
> need to push one forward.
>
> However, even if there
On 24/09/19 10:12AM, Denton Liu wrote:
> On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
> > +## Enforcement
> > +
> > +Instances of abusive, harassing, or otherwise unacceptable behavior may be
> > +reported by contacting the project team at g...@sfconservancy.org. All
> > +complaints w
Am 24.09.19 um 08:44 schrieb Jeff King:> +Examples of unacceptable behavior by
participants include:> +> +* The use of sexualized language or imagery and
unwelcome sexual attention or> + advances
Sure.
> +* Trolling, insulting/derogatory comments, and personal or political attacks
Hmm. Trolli
Hi,
This has been a long time since I have not given an update on this --
sorry about that. I think it’s time to do it.
Le 29/07/2019 à 11:38, Phillip Wood a écrit :
> Hi Alban
>
> -%<-
>
> That's an interesting point about `--continue`. Perhaps if `--edit-todo`
> detects deleted lines in erro
On Tue, Sep 24, 2019 at 10:12:14AM -0700, Denton Liu wrote:
> > I've cc'd g...@sfconservancy.org here, because I think it's important for
> > all of the project committee members to endorse it (and because the
> > document puts us on the hook for enforcing it!).
>
> I tried looking it up but I co
On 9/24/19 3:05 PM, Pratyush Yadav wrote:
On 24/09/19 10:12AM, Denton Liu wrote:
On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at g...@sfconserva
When the code comment in the zsh completion suggests that this file
should be copied to `~/.zsh`, many users might be misled to believe that
this refers to a file location. But it refers to a directory, and won't
work when it is a file.
Let's just add a slash, to make it abundantly clear that this
On Wed, Sep 25, 2019 at 01:35:33AM +0530, Pratyush Yadav wrote:
> > As I said above, I couldn't find a public list of the people who were on
> > the project committee. Perhaps that's because my Googling skills are bad
> > but I feel uncomfortable knowing that *anyone* will be given judge, jury
> >
On Tue, Sep 24, 2019 at 10:14:55PM +0200, René Scharfe wrote:
> > +* Trolling, insulting/derogatory comments, and personal or political
> > attacks
>
> Hmm. Trolling can be helpful, if done right. I consider this to be a
> good example: https://git-man-page-generator.lokaltog.net/. Wrote some
On Tue, Sep 24, 2019 at 02:08:53AM -0700, Denton Liu wrote:
> When we ran `make hdr-check`, we got the following warning on Arch Linux:
>
> pack-bitmap.h:20:19: error: ‘BITMAP_IDX_SIGNATURE’ defined but not used
> [-Werror=unused-const-variable=]
> 20 | static const char BITMAP_ID
On Tue, Sep 24, 2019 at 11:03:38AM +0200, Christian Schoenebeck wrote:
> > Yes, the resulting mail would be correct, in the sense that it could be
> > applied just fine by git-am. But I think it would be uglier. IOW, I
> > consider the presence of the in-body From to be a clue that something
> > i
On Tue, Sep 24, 2019 at 05:34:08PM -0400, Jeff King wrote:
> > I'm tacking this patch on since this warning didn't show up until I
> > compiled it on gcc 9.1.0.
>
> Curiously, I _don't_ see the warning with gcc 9.2.1. By my reading of
> the manpage, this should be triggered by -Wunused-const-vari
Hi list,
cc Pratyush,
While rebasing an old series, I had a 3-way merge fall back that didn't
show the `||| merged common ancestors` very well in git-gui.
That is, the conflict markers, and common ancestor lines, are treated as
being part of the current HEAD hunk, rather than being separa
Hi list,
cc Pratyush,
[resend without attached png file]
While rebasing an old series, I had a 3-way merge fall back that didn't
show the `||| merged common ancestors` very well in git-gui.
That is, the conflict markers, and common ancestor lines, are treated as
being part of the current
On 2019-09-24 at 06:44:54, Jeff King wrote:
> We've never had a formally written Code of Conduct document. Though it
> has been discussed off and on over the years, for the most part the
> behavior on the mailing list has been good enough that nobody felt the
> need to push one forward.
>
> Howeve
> > I've cc'd g...@sfconservancy.org here, because I think it's important for
> > all of the project committee members to endorse it (and because the
> > document puts us on the hook for enforcing it!).
>
> I tried looking it up but I couldn't find who the project committee
> members are. Is this l
fast-export allows specifying revision ranges, which can be used to
export a tag without exporting the commit it tags. fast-export handled
this rather poorly: it would emit a "from :0" directive. Since marks
start at 1 and increase, this means it refers to an unknown commit and
fast-import will c
Add a new option, --mark-tags, which will output mark identifiers with
each tag object. This improves the incremental export story with
--export-marks since it will allow us to record that annotated tags have
been exported, and it is also needed as a step towards supporting nested
tags.
Signed-of
Signed-off-by: Elijah Newren
---
builtin/fast-export.c | 30 ++
t/t9350-fast-export.sh | 2 +-
2 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index d32e1e9327..58a74de42a 100644
--- a/builtin/fast-export
fast-import has support for both an --import-marks flag and an
--import-marks-if-exists flag; the latter of which will not die() if the
file does not exist. fast-export only had support for an --import-marks
flag; add an --import-marks-if-exists flag for consistency.
Signed-off-by: Elijah Newren
If our input stream includes a tag which is later deleted, we were not
properly deleting it. We did have a step which would delete it, but we
left a tag in the tag list noting that it needed to be updated, and the
updating of annotated tags occurred AFTER ref deletion. So, when we
record that a t
fast-export and fast-import have nice --import-marks flags which allow
for incremental migrations. However, if there is a mark in
fast-export's file of marks without a corresponding mark in the one for
fast-import, then we run the risk that fast-export tries to send new
objects relative to the mar
Mark identifiers are used in fast-export and fast-import to provide a
label to refer to earlier content. Blobs are given labels because they
need to be referenced in the commits where they first appear with a
given filename, and commits are given labels because they can be the
parents of other com
This series improves the incremental export story for fast-export and
fast-import (--export-marks and --import-marks fell a bit short),
fixes a couple small export/import bugs, and enables handling nested
tags. In particular, the nested tags handling makes it so that
fast-export and fast-import ca
Multiple changes here:
* add a test for a tag of a blob
* add a test for a tag of a tag of a commit
* add a comment to the tests for (possibly nested) tags of trees,
making it clear that these tests are doing much less than you might
expect
Signed-off-by: Elijah Newren
---
t/t9350-
These patches fix a few problems identified by scan-build [1]. None of
them affect behavior, but they do make the code easier to follow and
ensure that the compiler is able to optimize it to the fullest.
-Alex
[1] https://clang-analyzer.llvm.org/scan-build.html
Alex Henrie (3):
commit-graph: r
Signed-off-by: Alex Henrie
---
commit-graph.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/commit-graph.c b/commit-graph.c
index 9b02d2c426..659f4bb4f4 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -1534,7 +1534,6 @@ static void split_graph_merge_strategy(struct
write_commit_graph_co
Signed-off-by: Alex Henrie
---
diffcore-break.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index 875aefd3fe..f6ab74141b 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -286,18 +286,17 @@ void diffcore_merge_broke
Signed-off-by: Alex Henrie
---
wrapper.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/wrapper.c b/wrapper.c
index c55d7722d7..c23ac6adcd 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -469,13 +469,12 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int
mode)
Pratyush,
once again, I had done this years ago. I may post an updated patch in
the evening:
https://github.com/bertwesarg/git-gui/commit/90ee4a8c260132a6b730040095929fd267cedd7b
Bert
On Wed, Sep 25, 2019 at 12:05 AM Philip Oakley wrote:
>
> Hi list,
> cc Pratyush,
>
> [resend without attached
On Tue, 24 Sep 2019, Johannes Schindelin wrote:
A CoC can very easily create clarity in such circumstances. By stating
explicitly the standards to which we promise to hold ourselves, as well as
others. And it can even help those who think of themselves as decent to
improve on that front.
As
65 matches
Mail list logo
