(Sent a reply from my phone while out of town but couldn't find it so here it
is again)
It's available on my github:
https://github.com/nmorey/git/tree/dev/curl-tunnel
The series had been stlighly changed since the patch were posted, mostly to add
the proper ifdefs to handle older curl versions
Le 16/08/2017 à 10:34, Jeff King a écrit :
> On Wed, Aug 09, 2017 at 04:43:26PM +0200, Nicolas Morey-Chaisemartin wrote:
>
>> I have a few doubt on patch #2:
>> - is socketpair working on all git supported system (windows ?)
> I'm pretty sure the answer is no, after searching a bit for mingw and
Either of these two options is CORRECT:
“Your branch is up to date …”
“You have an up-to-date branch …”
But “your branch is up-to-date” is INCORRECT. And, because it’s
incorrect, it conveys an odd and unsettling experience to native
English speakers whenever they read it.
If you’re curious,
The code base contains a few instances of "up-to-date" and "up to date".
A tree wide sweep could be made to update user-visible strings in the
code and in the documentation. Fixing source code comments seems like
overkill. Could I count on you to review any changes I'd propose? (With
respect to the
hIpPy venit, vidit, dixit 19.08.2017 00:35:
> While merging if I do certain actions then the merge commit is made
> with the merge message but as a normal (non-merge) commit.
>
> Repro steps:
> - Set GIT_MERGE_AUTOEDIT=yes (set other than "no") in .bashrc
> - Make a merge commit with no conflicts.
If the `git merge` process is killed while waiting for the editor to
finish, the merge state is lost but the prepared merge msg and tree is kept.
So, a subsequent `git commit` creates a squashed merge even when the
user asked for proper merge commit originally.
Save the merge state earlier (in the
Hello,
On Sun, Aug 20, 2017 at 8:03 PM, Job Snijders wrote:
> bump?
(As a side note, I have also noticed that gitweb patches tend to go
unreviewed for long)
> On Wed, Aug 02, 2017 at 08:59:01PM +0200, Job Snijders wrote:
>> We often work with very large plain text files in our repositories and
On 27/07/17 16:24, Junio C Hamano wrote:
> Phillip Wood writes:
>
>>> On 26/07/17 23:12, Junio C Hamano wrote:
I think
you are already 80% there without adding a yet another option,...
>>> ...
>>> I'm interested in the 20% as it's about 100% of my rebase conflicts.
>
> OK, then at leas
On Mon, Aug 21, 2017 at 12:19:38PM +0200, Giuseppe Bilotta wrote:
> >> This patch adds a 'raw' blob_plain link in history overview.
>
> Arguably, the addition of the 'raw' link should be done in the same
> conditional that also adds the 'diff to current' link, before the diff
> to current link.
>
Introduce function get_submodule_displaypath() to replace the code
occurring in submodule_init() for generating displaypath of the
submodule with a call to it.
This new function will also be used in other parts of the system
in later patches.
Mentored-by: Christian Couder
Mentored-by: Stefan Bel
Function set_name_rev() is ported from git-submodule to the
submodule--helper builtin. The function get_name_rev() generates the
value of the revision name as required, and the function
print_name_rev() handles the formating and printing of the obtained
revision name.
Mentored-by: Christian Couder
Introduce function for_each_submodule_list() and
replace a loop in module_init() with a call to it.
The new function will also be used in other parts of the
system in later patches.
Mentored-by: Christian Couder
Mentored-by: Stefan Beller
Signed-off-by: Prathamesh Chavan
---
builtin/submodule
This aims to make git-submodule 'status' a built-in. Hence, the function
cmd_status() is ported from shell to C. This is done by introducing
three functions: module_status(), submodule_status() and print_status().
The function module_status() acts as the front-end of the subcommand.
It parses subc
Hello
Earlier, I sent you an email on git@vger.kernel.org please confirm if you got
my message?
Angy Omari
Private Phone+447031903929
omaria...@yandex.com
The philosophy of reference locking has been, "if another process is
changing a reference, then whatever I'm trying to do to it will
probably fail anyway because my old-SHA-1 value is probably no longer
current". But this argument falls down if the other process has locked
the reference to do somet
With encoding on the file descriptor set to "binary" Tcl (8.6 in my case)
does double conversion which breaks e.g. author name in amended commits.
For example "\305\201ukasz" (as written by git cat-file) becomes
"\303\205\302\201ukasz".
Signed-off-by: Łukasz Stelmach
---
git-gui/lib/commit.tcl
So here's a little series.
1/3 I just noted along the way
2/3 splits the merge state writing into parts as a preparatory step.
This is something we may want to carry further and get rid of some other
places which write merge_msg unneccessarily so that merge performance
does not suffer because of
If the `git merge` process is killed while waiting for the editor to
finish, the merge state is lost but the prepared merge msg and tree is kept.
So, a subsequent `git commit` creates a squashed merge even when the
user asked for proper merge commit originally.
Save the merge state earlier (in the
write_merge_state() writes out the merge heads, mode, and msg. But we
may want to write out heads, mode without the msg. So, split out heads
(+mode) into a separate function write_merge_heads() that is called by
write_merge_state().
No funtional change so far.
Signed-off-by: Michael J Gruber
---
Currently, 'git merge --continue' is mentioned but not explained.
Explain it.
Signed-off-by: Michael J Gruber
---
Documentation/git-merge.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 6b308ab6d0..615e6
The error messages shown when the branch command is misused
by supplying it wrong number of parameters wasn't meaningful.
That's because it used the the phrase "too many branches"
assuming all parameters to be "valid" branch names. It's not
always the case as exemplified below,
$ git branc
The error messages shown when the branch command is misused
by supplying it wrong number of parameters wasn't meaningful.
That's because it used the the phrase "too many branches"
assuming all parameters to be "valid" branch names. It's not
always the case as exemplified below,
$ git branc
Sorry, wrong thread :( Please ignore this.
---
Kaartic
An "empty commit message" according to 'commit' has long been,
A message that contains only empty lines and/or whitespaces
and/or 'Signed-off-by' lines
This is biased as a commit message that contains only other trailers like
'Helped-by: ', 'Tested-by: ' etc., could equally be considered
Hello,
On Mon, Aug 21, 2017 at 12:44 PM, Job Snijders wrote:
> On Mon, Aug 21, 2017 at 12:19:38PM +0200, Giuseppe Bilotta wrote:
> Thank you for your feedback, good point. Please see below:
This looks fine
> ---
>
> Add a 'raw' blob_plain link in history overview
>
> Signed-off-by: Job Snijders
Add 'raw' blob_plain link in history overview
Reviewed-by: Giuseppe Bilotta
Signed-off-by: Job Snijders
---
gitweb/gitweb.perl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9208f42ed..959f04b49 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/
Commit 67a9dfcc00 ("hash-algo: integrate hash algorithm support with
repo setup", 21-08-2017) added a 'const struct git_hash_algo *hash_algo'
field to the repository structure, without modifying the initializer
of the 'the_repo' variable. This does not actually introduce a bug,
since the '0' initi
On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:
> As long as we are talking about idealized future world (well, at
> least an idea of somebody's "ideal", not necessarily shared by
> everybody), I wonder if there is even any need to have commits in
> submodules in such a world. To r
On Fri, Aug 18, 2017 at 11:24:47PM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > From: Lars Schneider
> >
> > Do not override the submodule configuration in the call to update
> > the submodules, but give a weaker default.
> >
> > Reported-by: Lars Schneider
> > Signed-off-by: Stef
On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:
> On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:
>> As long as we are talking about idealized future world (well, at
>> least an idea of somebody's "ideal", not necessarily shared by
>> everybody), I wonder if there is even any n
On 21 August 2017 at 14:53, Michael J Gruber wrote:
> Currently, 'git merge --continue' is mentioned but not explained.
>
> Explain it.
>
> Signed-off-by: Michael J Gruber
> ---
> Documentation/git-merge.txt | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentati
On Fri, Aug 18, 2017 at 11:51 PM, Junio C Hamano wrote:
> As long as we are talking about idealized future world (well, at
> least an idea of somebody's "ideal", not necessarily shared by
> everybody), I wonder if there is even any need to have commits in
> submodules in such a world. To realize
On Mon, Aug 21, 2017 at 09:45:14PM +0530, Prathamesh Chavan wrote:
> Function set_name_rev() is ported from git-submodule to the
> submodule--helper builtin. The function get_name_rev() generates the
> value of the revision name as required, and the function
> print_name_rev() handles the formating
Heiko Voigt writes:
> So I think it is important that there are commits in the submodule so
> its history makes sense independently for others.
I was trying to push the "just like trees" to the logical conclusion
in order to see see if it leads to an absurd conclusions, or some
useful scenario.
On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote:
>> So I am a bit curious to learn which part of this change you dislike
>> and why.
>
> I am also curious. Isn't this the same strategy we are using in other
> places?
>
I dislike it because the UX feels crude. When reading the documentation,
> On 21 Aug 2017, at 18:55, Stefan Beller wrote:
>
> On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote:
>
>>> So I am a bit curious to learn which part of this change you dislike
>>> and why.
>>
>> I am also curious. Isn't this the same strategy we are using in other
>> places?
>>
>
> I di
On Mon, Aug 21, 2017 at 10:17 PM, Heiko Voigt wrote:
> On Mon, Aug 21, 2017 at 09:45:14PM +0530, Prathamesh Chavan wrote:
>> Function set_name_rev() is ported from git-submodule to the
>> submodule--helper builtin. The function get_name_rev() generates the
>> value of the revision name as required
This is the second version of my series to try to address some issues
noted by ThreadSanitizer. Thanks to all who took the time to provide
input on the first version.
The largest change is in the third patch, which moves the "avoid writing
to slopbuf"-logic into strbuf_setlen, and compiles it unco
strbuf_setlen(., 0) writes '\0' to sb.buf[0], where buf is either
allocated and unique to sb, or the global slopbuf. The slopbuf is meant
to provide a guarantee that buf is not NULL and that a freshly
initialized buffer contains the empty string, but it is not supposed to
be written to. That strbuf
When checking the conditional of "while (me->remaining)", we did not
hold the lock. Calling find_deltas would still be safe, since it checks
"remaining" (after taking the lock) and is able to handle all values. In
fact, this could (currently) not trigger any bug: a bug could happen if
`remaining` t
convert_attrs contains an "if-else". In the "if", we set attr_action
twice, and the first assignment has no effect. In the "else", we do not
set it at all. Since git_check_attr always returns the same value, we'll
always end up in the "if", so there is no problem right now. But
convert_attrs is obv
Add a file .tsan-suppressions and list two functions in it: want_color()
and transfer_debug(). Both of these use the pattern
static int foo = -1;
if (foo < 0)
foo = bar();
where bar always returns the same non-negative value. This can cause
ThreadSanitizer to diagn
On Mon, Aug 21, 2017 at 10:20 AM, Lars Schneider
wrote:
>
>> On 21 Aug 2017, at 18:55, Stefan Beller wrote:
>>
>> On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote:
>>
So I am a bit curious to learn which part of this change you dislike
and why.
>>>
>>> I am also curious. Isn't this t
On Sat, Aug 19, 2017 at 9:53 AM, René Scharfe wrote:
> Am 19.08.2017 um 07:33 schrieb René Scharfe:
>> When read_tree_recursive() encounters a directory excluded by a pathspec
>> then it enters it anyway because it might contain included entries. It
>> calls the callback function before it is abl
On 08/21, Stefan Beller wrote:
> On Mon, Aug 21, 2017 at 10:20 AM, Lars Schneider
> wrote:
> >
> >> On 21 Aug 2017, at 18:55, Stefan Beller wrote:
> >>
> >> On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote:
> >>
> So I am a bit curious to learn which part of this change you dislike
>
On Sat, 19 Aug 2017 23:40:33 -0700
Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > I have to say that this was a painful topic to integrate.
> >
> > As you may know, the mk/use-size-t-in-zlib topic is being retracted
> > and getting rerolled as a larger size_t series, most of which still
>
+cc git gui maintainer
On Mon, Aug 21, 2017 at 4:53 AM, Łukasz Stelmach wrote:
> With encoding on the file descriptor set to "binary" Tcl (8.6 in my case)
> does double conversion which breaks e.g. author name in amended commits.
>
> For example "\305\201ukasz" (as written by git cat-file) become
On Sun, Aug 20, 2017 at 5:00 PM, brian m. carlson
wrote:
> = Overview
>
> This is an RFC series proposing a basic abstraction for hash functions.
>
> As we get closer to converting the remainder of the codebase to use
> struct object_id, we should think about the design we want our hash
> function
SUMMARY OF MY PROJECT:
Git submodule subcommands are currently implemented by using shell script
'git-submodule.sh'. There are several reasons why we'll prefer not to
use the shell script. My project intends to convert the subcommands into
C code, thus making them builtins. This will increase Git'
On Sun, Aug 20, 2017 at 5:00 PM, brian m. carlson
wrote:
> Since in the future we want to support an additional hash algorithm, add
> a structure that represents a hash algorithm and all the data that must
> go along with it. Add a constant to allow easy enumeration of hash
> algorithms. Impleme
On Sun, Aug 20, 2017 at 5:00 PM, brian m. carlson
wrote:
> In future versions of Git, we plan to support an additional hash
> algorithm. Integrate the enumeration of hash algorithms with repository
> setup, and store a pointer to the enumerated data in struct repository.
> Of course, we currently
When writing out the index, the ondisk struct was being allocated and freed
within the loop of cache entries. A better way would be to use a ondisk
struct on the stack and reuse it avoiding the alloc and free calls.
A test has been added to measure the performance of writing the index
(p0007-writ
The previous_name_buf was never getting released when there
was an error in ce_write_entry or allow was false and execution
was returned to the caller.
Signed-off-by: Kevin Willford
---
read-cache.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/read-cache.c b/r
When writing the index for each entry an ondisk struct will be
allocated and freed in ce_write_entry. We can do better by
using a ondisk struct on the stack for each entry.
This is accomplished by using a stack ondisk_cache_entry_extended
outside looping through the entries in do_write_index. On
A performance test for writing the index to be able to
determine if changes to allocating ondisk structure help.
Signed-off-by: Kevin Willford
---
Makefile| 1 +
t/helper/test-write-cache.c | 23 +++
t/perf/p0007-write-cache.sh | 29 ++
Martin Ågren writes:
>> But “your branch is up-to-date” is INCORRECT. And, because it’s
>> incorrect, it conveys an odd and unsettling experience to native
>> English speakers whenever they read it.
>>
>> If you’re curious, you can find plenty of discussion of this point of
>> grammar. Here’s jus
Phillip Wood writes:
> ... I prefer
> having to pass --autostage with --continue so that it is a concious
> decision by the user to stage unstaged changes when they continue rather
> than rebase just doing it each time it continues.
In other words, instead of
git add -u && git rebase --
Stefan Beller writes:
> On Fri, Aug 18, 2017 at 11:51 PM, Junio C Hamano wrote:
>
>> As long as we are talking about idealized future world (well, at
>> least an idea of somebody's "ideal", not necessarily shared by
>> everybody), I wonder if there is even any need to have commits in
>> submodul
Brandon Williams writes:
>> > I tried to make it work here:
>> > https://public-inbox.org/git/89ab8aa3-8e19-46ba-b169-d1ea4cf4a...@gmail.com/
>>
>> (A) you need to set expect there as well, to have sub{2,4,5} be expected
>> there as well.
>>
>> (B) That may hint at another (UX) bug.
>>
>> The
Jonathan Tan writes:
> On Sat, 19 Aug 2017 23:40:33 -0700
> Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>> > I have to say that this was a painful topic to integrate.
>> >
>> > As you may know, the mk/use-size-t-in-zlib topic is being retracted
>> > and getting rerolled as a larger si
Hello!
I am Mrs Wang Ling, I work at Lloyds TSB pacific LTD, I have a business
proposal, contact me so i will tell you all about this proposal .
Kind Regards
Mrs Wang Ling
Kevin Willford writes:
> The previous_name_buf was never getting released when there
> was an error in ce_write_entry or allow was false and execution
> was returned to the caller.
>
> Signed-off-by: Kevin Willford
> ---
Thanks for spotting an old error that dates back to at least 2013
this mon
Kevin Willford writes:
> When writing the index for each entry an ondisk struct will be
> allocated and freed in ce_write_entry. We can do better by
> using a ondisk struct on the stack for each entry.
>
> This is accomplished by using a stack ondisk_cache_entry_extended
> outside looping throug
Michael J Gruber writes:
> write_merge_state() writes out the merge heads, mode, and msg. But we
> may want to write out heads, mode without the msg. So, split out heads
> (+mode) into a separate function write_merge_heads() that is called by
> write_merge_state().
>
> No funtional change so far.
Michael J Gruber writes:
> Currently, 'git merge --continue' is mentioned but not explained.
>
> Explain it.
>
> Signed-off-by: Michael J Gruber
> ---
> Documentation/git-merge.txt | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-merge.txt b/Documen
Michael J Gruber writes:
> static void prepare_to_commit(struct commit_list *remoteheads)
> {
> struct strbuf msg = STRBUF_INIT;
> @@ -767,6 +768,8 @@ static void prepare_to_commit(struct commit_list
> *remoteheads)
> strbuf_commented_addf(&msg, _(merge_editor_comment),
>
On Sun, Aug 20, 2017 at 11:42:35PM -0700, Junio C Hamano wrote:
> Martin Koegler writes:
>
> > From: Martin Koegler
> >
> > Signed-off-by: Martin Koegler
> > ---
> > archive-tar.c | 16
> > archive-zip.c | 22 +++---
> > 2 files changed, 19 insertions(+), 19 de
On Mon, Aug 21, 2017 at 04:48:42PM +0100, Ramsay Jones wrote:
>
> Commit 67a9dfcc00 ("hash-algo: integrate hash algorithm support with
> repo setup", 21-08-2017) added a 'const struct git_hash_algo *hash_algo'
> field to the repository structure, without modifying the initializer
> of the 'the_rep
Hej,
I found 2 threads about hanging t5551, one in 2016, and one question
from Junio somewhen in 2017.
I have it reproducable here:
- Debian 8, 64 bit
- SSD
- Half-modern processor ;-)
The last thing I can see is:
ok 29 - test allowanysha1inwant with unreachable
---
A simplified ps -ef sho
Hello, Torsten.
On Tue, Aug 22, 2017 at 07:10:59AM +0200, Torsten Bögershausen wrote:
> Hej,
> I found 2 threads about hanging t5551, one in 2016, and one question
> from Junio somewhen in 2017.
> I have it reproducable here:
> - Debian 8, 64 bit
> - SSD
> - Half-modern processor ;-)
I don't thi
71 matches
Mail list logo
