On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote:
> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin wrote:
> > Anyway, now I am compelled to use github which is also a fine tool and I
> > appreciate all of the work that has gone into it. About 80% of the time,
> > I rebase and force push
On Tue, Dec 26, 2017 at 9:11 AM, Duy Nguyen wrote:
> On Mon, Dec 25, 2017 at 07:26:27PM +0100, Igor Djordjevic wrote:
>> But I`ve noticed that "--porcelain=v2" output might still be buggy -
>> this is what having both files staged shows:
>>
>> $ git status --porcelain=v2
>> 2 R. N... 10064
On Mon, Dec 25, 2017 at 07:26:27PM +0100, Igor Djordjevic wrote:
> But I`ve noticed that "--porcelain=v2" output might still be buggy -
> this is what having both files staged shows:
>
> $ git status --porcelain=v2
> 2 R. N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78
>
On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin wrote:
> Anyway, now I am compelled to use github which is also a fine tool and I
> appreciate all of the work that has gone into it. About 80% of the time,
> I rebase and force push to my branch to update a pull request. I've come
> to like the end pr
On Mon, Dec 25, 2017 at 4:16 PM, Carl Baldwin wrote:
> On Sat, Dec 23, 2017 at 11:09:59PM +0100, Ęvar Arnfjörš Bjarmason wrote:
>> >> But I don't see why you think this needs a new "replaces" parent
>> >> pointer orthagonal to parent pointers, i.e. something that would
>> >> need to be a new field
On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote:
> As a suggestion, before diving into the technical details of your
> proposal, it might be useful consider the usage scenario you are
> targetting. Things like "git rebase" and "git merge" and your
> proposed "git replace/replay" are
On Sat, Dec 23, 2017 at 11:09:59PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> But I don't see why you think this needs a new "replaces" parent
> >> pointer orthagonal to parent pointers, i.e. something that would
> >> need to be a new field in the commit object (I may have misread the
> >> proposal
On December 25, 2017 6:44 PM Carl Baldwin wrote:
> On Sun, Dec 24, 2017 at 12:01:38AM +0100, Johannes Schindelin wrote:
> > On Sat, 23 Dec 2017, Carl Baldwin wrote:
> > > I imagine that a "git commit --amend" would also insert a "replaces"
> > > reference to the original commit but I failed to ment
On Mon, Dec 25, 2017 at 10:39 PM, Liam Beguin wrote:
> I'm curious, how did you build to get this error to show?
> I tried with the DEVELOPER 'flag' but nothing showed and -Wextra gave
> way too much messages...
> Did you just add -Wignored-qualifiers to CFLAGS?
I have a custom CFLAGS, created be
On Sun, Dec 24, 2017 at 12:01:38AM +0100, Johannes Schindelin wrote:
> Hi Carl,
>
> On Sat, 23 Dec 2017, Carl Baldwin wrote:
>
> > I imagine that a "git commit --amend" would also insert a "replaces"
> > reference to the original commit but I failed to mention that in my
> > original post.
>
> A
On 25/12/2017 20:45, Igor Djordjevic wrote:
>
> I guess an additional test for this would be good, too.
... aaand here it is. Again based on your test, but please double
check, I`m not sure if it`s ok to compare file modes like that,
expecting them to be the same (hashes should be fine, I guess
On Sat, Dec 23, 2017 at 05:19:35PM -0500, Randall S. Becker wrote:
> No matter how this plays out, let's please make very sure to provide
> sufficient user documentation so that those of us who have to explain
> the differences to users have a decent reference. Even now, explaining
> rebase vs. mer
On 25/12/2017 19:26, Igor Djordjevic wrote:
>
> But I`ve noticed that "--porcelain=v2" output might still be buggy -
> this is what having both files staged shows:
>
> $ git status --porcelain=v2
> 2 R. N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78
> 12f00e90b6ef791
On Mon, Dec 25 2017, Duy Nguyen jotted:
> On Fri, Dec 22, 2017 at 9:00 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> The untracked cache gets confused when a directory is swapped out for
>> a symlink to another directory. Whatever files are inside the target
>> of the symlink will be incorrectly shown
Hi Duy,
On 25/12/2017 11:37, Nguyễn Thái Ngọc Duy wrote:
> Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist
> in index" - 2016-10-24) there are never "new files" in the index, which
> essentially disables rename detection because we only detect renames
> when a new file app
On Sun, Dec 24, 2017 at 8:35 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Sun, Dec 24 2017, Kevin Daudt jotted:
>
>> On Sun, Dec 24, 2017 at 12:15:35PM +0400, Vadim Petrov wrote:
>>> Thank you for your replay.
>>>
>>> > I have to be honest: this commit message (including the subject) left me
>>> > qu
Signed-off-by: Rene Scharfe
---
commit.c | 14 --
commit.h | 1 -
2 files changed, 15 deletions(-)
diff --git a/commit.c b/commit.c
index 9edc12f338..ff51c9f34a 100644
--- a/commit.c
+++ b/commit.c
@@ -559,20 +559,6 @@ void clear_commit_marks(struct commit *commit, unsigned
int mar
Signed-off-by: Rene Scharfe
---
revision.c | 3 +--
revision.h | 12
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/revision.c b/revision.c
index f6a3da5cd9..7239315de9 100644
--- a/revision.c
+++ b/revision.c
@@ -2860,8 +2860,7 @@ int prepare_revision_walk(struct re
The leak_pending flag is so awkward to use that multiple comments had to
be added around each occurrence. We only use it for remembering the
commits whose marks we have to clear after checking if the old HEAD is
detached. This is easy, though: We need to do that for the old commit,
the new one --
The leak_pending flag is so awkward to use that multiple comments had to
be added around each occurrence. We only use it for remembering the
commits whose marks we have to clear after checking if all of the good
ones are ancestors of the bad one. This is easy, though: We need to do
that for the b
The leak_pending flag is so awkward to use that multiple comments had to
be added around each occurrence. We use it for remembering the
prerequisites for the bundle. That is easy, though: We have the
ref_list named "prerequisites" in the header for just that purpose.
Use this original list of pr
Add a function for clearing the commit marks of all in-core commit
objects. It's similar to clear_object_flags(), but more precise, since
it leaves the other object types alone. It still has to iterate through
them, though.
Signed-off-by: Rene Scharfe
---
object.c | 11 +++
object.h |
Signed-off-by: Rene Scharfe
---
ref-filter.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index 3f9161707e..f9e25aea7a 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1995,8 +1995,7 @@ static void do_merge_filter(struct ref_filter_cbdata
*ref
Pass the entries of the commit array directly to clear_commit_marks_1()
instead of adding them to a commit_list first. The function clears the
commit and any first parent without allocation; only higher numbered
parents are added to a list for later treatment. This change extends
that optimizatio
Signed-off-by: Rene Scharfe
---
commit.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index 82667514bd..9edc12f338 100644
--- a/commit.c
+++ b/commit.c
@@ -929,8 +929,7 @@ static int remove_redundant(struct commit **array, int cnt)
The flag leak_pending is weird, let's get rid of it.
Changes from v1: Everything.
An independent optimization found while working on this series:
commit: avoid allocation in clear_commit_marks_many()
Trivial unrelated conversions (included as bonus patches):
commit: use clear_commit_marks_
Am 24.12.2017 um 15:22 schrieb Jeff King:
> The single-traversal thing I suspect doesn't matter much in practice. In
> both cases if we would visit commit X twice, we'd immediately see on the
> second visit that it has already been cleared and not do anymore work.
Good point. That makes clear_com
Hi Duy,
On Mon, 25 Dec 2017 at 07:48 Duy Nguyen wrote:
>
> On Mon, Dec 4, 2017 at 5:17 AM, Liam Beguin wrote:
> > +static const char command_to_char(const enum todo_command command)
> > +{
> > + if (command < TODO_COMMENT && todo_command_info[command].c)
> > + return todo_com
On Mon, Dec 4, 2017 at 5:17 AM, Liam Beguin wrote:
> +static const char command_to_char(const enum todo_command command)
> +{
> + if (command < TODO_COMMENT && todo_command_info[command].c)
> + return todo_command_info[command].c;
> + return comment_line_char;
> +}
C
On Fri, Dec 22, 2017 at 9:00 PM, Ævar Arnfjörð Bjarmason
wrote:
> The untracked cache gets confused when a directory is swapped out for
> a symlink to another directory. Whatever files are inside the target
> of the symlink will be incorrectly shown as untracked. This issue does
> not happen if th
Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist
in index" - 2016-10-24) there are never "new files" in the index, which
essentially disables rename detection because we only detect renames
when a new file appears in a diff pair.
After that commit, an i-t-a entry can appear
Not sure if I should add a CVE-2009-0037 reference as well.
---
http.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/http.c b/http.c
index 215bebe..26b3386 100644
--- a/http.c
+++ b/http.c
@@ -802,7 +802,7 @@ static CURL *get_curl_handle(void)
get_curl_allowed_protocols(-1));
Am 24.12.2017 um 15:54 schrieb Jeff King:
On Sat, Nov 18, 2017 at 10:01:45AM +0100, Johannes Sixt wrote:
Yeah, I have mixed feelings on that. I think it does make the control
flow less clear. At the same time, what I found was that handlers like
die/ignore/warn were the thing that gave the most
Am 25.12.2017 um 01:28 schrieb Ævar Arnfjörð Bjarmason:
+create_test_file() {
+ file=$1
+
+ case $file in
+ # `touch .` will succeed but obviously not do what we intend
+ # here.
+ ".")
+ return 1
+ ;;
+ # We cannot create a file wit
On Sat, Dec 23, 2017 at 9:42 AM, Alex Vandiver wrote:
> I just stumbled across the following oddity:
Thanks. I'm looking into it.
--
Duy
On Friday 22 December 2017 05:19 PM, Johannes Schindelin wrote:
Hi Kaartic,
I think I didn't mention I've set `commit.gpgsign` to `true` for that
repo, did I?
Hah! I had troubles to associate the correct line in my versions of Git's
source code (the line numbers alone are only reliable if yo
36 matches
Mail list logo