From: Kaartic Sivaraam
The documentation for 'create_branch()' was incomplete as it didn't say
what certain parameters were used for. Further a parameter name wasn't
very communicative.
So, add missing documentation for the sake of completeness and easy
reference. Also, rename the concerned para
Sorry, ignore this mails. I actually have re-sent it to the correct
thread.
--
Kaartic
From: Kaartic Sivaraam
The ad-hoc patches to add new arguments to a function when needed
resulted in the related arguments not being close to each other.
This misleads the person reading the code to believe that there isn't
much relation between those arguments while it's not the case.
So, re-or
This parameter allows the branchname validation functions to
optionally return a flag specifying the reason for failure, when
requested. This allows the caller to know why it was about to die.
This allows more useful error messages to be given to the user when
trying to rename a branch.
The flags
From: Kaartic Sivaraam
When trying to rename an inexistent branch to with a name of a branch
that already exists the rename failed specifying the new branch name
exists rather than specifying that the branch trying to be renamed
doesn't exist.
$ git branch -m tset master
fatal: A branch
In builtin/branch, the error messages weren't handled directly by the branch
renaming function and was left to the other function. Though this avoids
redundancy this gave unclear error messages in some cases. So, make
builtin/branch
give more useful error messages.
Changes in v3:
Incorpo
From: Kaartic Sivaraam
When trying to rename an inexistent branch to with a name of a branch
that already exists the rename failed specifying the new branch name
exists rather than specifying that the branch trying to be renamed
doesn't exist.
$ git branch -m tset master
fatal: A branch
From: Kaartic Sivaraam
The ad-hoc patches to add new arguments to a function when needed
resulted in the related arguments not being close to each other.
This misleads the person reading the code to believe that there isn't
much relation between those arguments while it's not the case.
So, re-or
From: Kaartic Sivaraam
The documentation for 'create_branch()' was incomplete as it didn't say
what certain parameters were used for. Further a parameter name wasn't
very communicative.
So, add missing documentation for the sake of completeness and easy
reference. Also, rename the concerned para
In builtin/branch, the error messages weren't handled directly by the branch
renaming function and was left to the other function. Though this avoids
redundancy this gave unclear error messages in some cases. So, make
builtin/branch
give more useful error messages.
Changes in v3:
Incorpo
This parameter allows the branchname validation functions to
optionally return a flag specifying the reason for failure, when
requested. This allows the caller to know why it was about to die.
This allows more useful error messages to be given to the user when
trying to rename a branch.
The flags
On Wed, Nov 1, 2017 at 3:41 PM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Wed, 1 Nov 2017, Stefan Beller wrote:
>
>> >> I know id prefer the first commit that introduced the blob. That's
>> >> what describing a commit does, it finds the oldest tag prior to the
>> >> commit, while --contains f
I was able to spare some time to dig into this and found a few things.
First, it seems that the issue is more generic and the BUG kicks in
whenever HEAD is not a symbolic ref. I noticed that because when HEAD
is a symbolic ref there was a change in the error message shown by git.
In (2.11.0) I get
Junio C Hamano writes:
> Simon Ruderich writes:
>
>> All other error messages in the file use quotes around the file name.
>>
>> This change removes two translations as "could not write to '%s'" and
>> "could not close '%s'" are already translated and these two are the only
>> occurrences withou
Martin Ågren writes:
> `find_bisection()` rebuilds the commit list it is given by reversing it
> and skipping uninteresting commits. The uninteresting list entries are
> leaked. Free them to fix the leak.
>
> While we're here and understand what's going on, document the function.
> In particular,
Simon Ruderich writes:
> All other error messages in the file use quotes around the file name.
>
> This change removes two translations as "could not write to '%s'" and
> "could not close '%s'" are already translated and these two are the only
> occurrences without quotes.
>
> Signed-off-by: Simo
Junio C Hamano writes:
> The reason why we say "-ish" is "Yes we know v2.15.0 is *NOT* a
> commit object, we very well know it is a tag object, but because we
> allow it to be used in a context that calls for a commit object, we
> mark that use context as 'this accepts commit-ish, not just
> comm
Martin Ågren writes:
> diff --git a/builtin/merge-base.c b/builtin/merge-base.c
> index 6dbd167d3..b1b7590c4 100644
> --- a/builtin/merge-base.c
> +++ b/builtin/merge-base.c
> @@ -59,6 +59,8 @@ static int handle_independent(int count, const char **args)
> commit_list_insert(get_comm
René Scharfe writes:
> @@ -807,6 +816,8 @@ static int get_cmd_result(struct imap_store *ctx, struct
> imap_cmd *tcmd)
> if (cmdp->cb.cont || cmdp->cb.data)
> imap->literal_pending = 0;
> arg = next_arg(&cmd);
> +
Stefan Beller writes:
> But now we have a path as well, the notation of
> COLON
> is not a unique description of the blob, because
> * there can be multiple s depending on the tags and walking
> * in boilerplate code cases, we might even have the blob at different
> places (e.g. pristine copi
Junio C Hamano writes:
> Stefan Beller writes:
>
>> Signed-off-by: Stefan Beller
>> ---
>> t/t6120-describe.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Good. I am guessing that you are sending this as the last/optional
> one because this was found _after_ you worked on oth
Johannes Schindelin writes:
>> > I feel this is the wrong way round. `>/dev/null` may sound very intuitive
>> > to you, but this feature is Windows only. Guess three times how intuitive
>> > it sounds to Windows developers to write `>/dev/null` if you want to
>> > suppress output...
>>
>> It wou
Antoine Beaupré writes:
> It might still worth fixing this, but I'm not sure what the process is
> here - in the latest "what's cooking" Junio said this patchset would be
> merged in "next". Should I reroll the patchset to fix this or not?
The process is for you (the contributor of the topic) to
Johannes Schindelin writes:
>> > Given that the test_expect_* functions evaluate the code, it makes me
>> > wonder whether those `return` statements really return appropriately, or
>> > one call level too low.
>>
>> The test_expect functions eval the actual snippets inside a dummy
>> function. T
Jonathan Tan writes:
> Junio, would you prefer that the combined effort be in one single patch
> series or separated out into 3? The way I see it, there are two
> independent patch series - this one (object filter support in rev-list
> and pack-objects) and my one (repo extension for partial clon
> The options are currently only referenced by the git-blame man page,
> also explain them in git-config, which is the canonical page to
> contain all config options.
Good idea.
> Signed-off-by: Stefan Beller
> ---
> Documentation/config.txt | 17 +
> 1 file changed, 17 insertio
On Wed, Nov 1, 2017 at 3:41 PM, Johannes Schindelin
wrote:
>> The current implementation gives C, though.
>> (assuming C is HEAD, and A is ancient)
>>
>> With the --reverse flag one of B or D is given (not sure which,
>> depends on the exact order).
>
> Sure, but it is still a tricky thing. Imagi
Be our agent in your region. Reply for more details.
On Wed, Nov 1, 2017 at 3:39 PM, Johannes Schindelin
wrote:
>> not ok 1 - witty title
>>
>> That is all we want to care about here?
>
> We care about the loop body being executed successfully *each time*. A
> better counter example:
Good point. I'll use return in that case. Thanks!
Stefan
Hi Stefan,
On Wed, 1 Nov 2017, Stefan Beller wrote:
> >> I know id prefer the first commit that introduced the blob. That's
> >> what describing a commit does, it finds the oldest tag prior to the
> >> commit, while --contains finds the first tag that contains the commit
> >> as an ancestor.
> >
Hi Stefan,
On Wed, 1 Nov 2017, Stefan Beller wrote:
> We do not care about the internal state, aborting early, we rather
> care only if the whole loop body was executed. Running the test
>
> test_expect_success 'witty title' '
> for a in 1 2 3; do echo $a && false; done && echo done
Hi,
On Wed, 1 Nov 2017, Jeff King wrote:
> On Wed, Nov 01, 2017 at 10:36:02PM +0100, Johannes Schindelin wrote:
>
> > On Wed, 1 Nov 2017, Junio C Hamano wrote:
> >
> > > On Wed, Nov 1, 2017 at 9:26 PM, Johannes Schindelin
> > > wrote:
> > > >
> > > > ...
> > > > (
> > > >
The options are currently only referenced by the git-blame man page,
also explain them in git-config, which is the canonical page to
contain all config options.
Signed-off-by: Stefan Beller
---
Documentation/config.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Docume
On Wed, Nov 1, 2017 at 9:42 AM, Stefan Beller wrote:
>> So it may make more sense just to cross-reference those merges with the
>> topics that spawned them on the mailing list. I.e., instead of copying
>> the cover letter contents, just record the message-id (and update it
>> whenever a new itera
>> I know id prefer the first commit that introduced the blob. That's what
>> describing a commit does, it finds the oldest tag prior to the commit,
>> while --contains finds the first tag that contains the commit as an
>> ancestor.
>
> It is very easy to wish for "the oldest commit introducing a b
>> I think I'll go without the extra subshell and with s/return 1/false/ as
>> the exact value doesn't matter.
>
> You mean
>
> for ...
> do
> xyz ||
> false
> done
Yes, I do.
> ? That does not work. Try this:
>
> for a in 1 2 3; do
Hi Junio,
On Wed, 1 Nov 2017, Junio C Hamano wrote:
> * jk/rebase-i-exec-gitdir-fix (2017-11-01) 1 commit
> - sequencer: pass absolute GIT_DIR to exec commands
>
> A recent regression in "git rebase -i" that broke execution of git
> commands from subdirectories via "exec" insn has been fixed.
On Wed, Nov 01, 2017 at 10:46:14PM +0100, Johannes Schindelin wrote:
> > - it calls die() rather than returning an error. Looking at the
> > callsites, I'm inclined to say that would be fine. Failing to write
> > to the todo file is essentially a fatal error for sequencer code.
>
> I sp
On Wed, Nov 01, 2017 at 10:59:49PM +0100, René Scharfe wrote:
> > The hex_to_bytes() function requires that the caller make sure they have
> > the right number of bytes. But for many callers, I think they'd want to
> > say "parse this oid, which might be truncated; I can't tell what the
> > length
Hi,
On Wed, 1 Nov 2017, Jacob Keller wrote:
> On November 1, 2017 10:59:08 AM PDT, Stefan Beller wrote:
> >>> Does the code describe a9dbc3f12c as v2.15.0:GIT-VERSION-GEN, or
> >>> would it always be :?
> >>
> >> As the blob is described using this function:
> >>
> >> static void process_object(
View the enclosed file for your Compensation Reinbursement
Code Payment.pdf
Description: Adobe PDF document
Hi Stefan,
On Wed, 1 Nov 2017, Stefan Beller wrote:
> On Wed, Nov 1, 2017 at 5:37 AM, Junio C Hamano wrote:
> > On Wed, Nov 1, 2017 at 9:26 PM, Johannes Schindelin
> > wrote:
> >>
> >> ...
> >> (
> >> for x in four three
> >> do
> >>
Am 01.11.2017 um 20:55 schrieb Jeff King:
> On Tue, Oct 31, 2017 at 02:49:56PM +0100, René Scharfe wrote:
>
>> The path of a loose object contains its hash value encoded into two
>> substrings of hexadecimal digits, separated by a slash. The current
>> code copies the pieces into a temporary buff
Hi Matthew,
On Wed, 1 Nov 2017, Matthew Orres wrote:
> Using 2.15.0 on OSX 10.12.6, when I open git gui, and then attempt to
> stage multiple files as such:
>
> * Left click first file
> * CMD+Shift+Click last file to multi-select all files
> * CMT+T (shortcut for Stage to Commit)
>
> Only the
Hi Peff,
On Wed, 1 Nov 2017, Jeff King wrote:
> On Tue, Oct 31, 2017 at 10:54:21AM +0100, René Scharfe wrote:
>
> > Reduce code duplication by extracting a function for rewriting an
> > existing file.
>
> These patches look like an improvement on their own, but I wonder if we
> shouldn't just b
On Tue, Oct 31, 2017 at 9:11 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +If the given object refers to a blob, it will be described
>> +as `:`, such that the blob can be found
>> +at `` in the ``. Note, that the commit is likely
>
> Does the code describe a9dbc3f12c as v2.15.0:GIT-VER
On Wed, Nov 01, 2017 at 10:36:02PM +0100, Johannes Schindelin wrote:
> Hi Junio,
>
> On Wed, 1 Nov 2017, Junio C Hamano wrote:
>
> > On Wed, Nov 1, 2017 at 9:26 PM, Johannes Schindelin
> > wrote:
> > >
> > > ...
> > > (
> > > for x in four three
> > >
Hi Junio,
On Wed, 1 Nov 2017, Junio C Hamano wrote:
> On Wed, Nov 1, 2017 at 9:26 PM, Johannes Schindelin
> wrote:
> >
> > ...
> > (
> > for x in four three
> > do
> > git rm $x &&
> > git commit -m "
Hi Jake,
On Tue, 31 Oct 2017, Jacob Keller wrote:
> From: Jacob Keller
>
> When we replaced the old shell script based interactive rebase in
> commmit 18633e1a22a6 ("rebase -i: use the rebase--helper builtin",
> 2017-02-09) we introduced a regression of functionality in that the
> GIT_DIR would
On Wed, Nov 01, 2017 at 09:45:06PM +0100, Martin Ågren wrote:
> With --recurse-submodules, we add each submodule that we encounter to
> the list of alternate object databases. With threading, our changes to
> the list are not protected against races. Indeed, ThreadSanitizer
> reports a race when w
On November 1, 2017 10:59:08 AM PDT, Stefan Beller wrote:
>>> Does the code describe a9dbc3f12c as v2.15.0:GIT-VERSION-GEN, or
>>> would it always be :?
>>
>> As the blob is described using this function:
>>
>> static void process_object(struct object *obj, const char *path, void
>*data)
>> {
>>
On Tue, Oct 31, 2017 at 8:34 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> Given the difficulty in
>>> coming up with the single-liner description of what it does we saw
>>> above, I suspect that splitting SYNOPSIS out into two very distinct
>>> operating mode might make it easier to r
On 11/01, Martin Ågren wrote:
> With --recurse-submodules, we add each submodule that we encounter to
> the list of alternate object databases. With threading, our changes to
> the list are not protected against races. Indeed, ThreadSanitizer
> reports a race when we call `add_to_alternates_memory(
With --recurse-submodules, we add each submodule that we encounter to
the list of alternate object databases. With threading, our changes to
the list are not protected against races. Indeed, ThreadSanitizer
reports a race when we call `add_to_alternates_memory()` around the same
time that another t
After we have sorted the `cnt`-many commits that we have selected, we
place them into the commit list. We then set `p->next` to NULL, but as
we do so, `p` is already pointing one beyond item number `cnt`. Indeed,
we check whether `p` is NULL before dereferencing it.
This only matters if there are
When `find_bisection()` returns a single list entry, it leaks the other
entries. Move the to-be-returned item to the front and free the
remainder.
Signed-off-by: Martin Ågren
---
bisect.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/bisect.c b/bisect.c
index fda527b89
`find_bisection()` rebuilds the commit list it is given by reversing it
and skipping uninteresting commits. The uninteresting list entries are
leaked. Free them to fix the leak.
While we're here and understand what's going on, document the function.
In particular, make sure to document that the or
On Sun, Oct 29, 2017 at 10:51 PM, Antoine Beaupré wrote:
> Without this, the fetch process seems hanged while we fetch page
> listings across the namespaces. Obviously, it should be possible to
> silence this with -q, but that's an issue already present everywhere
> in the code and should be fixed
On Sun, Oct 29, 2017 at 10:51 PM, Antoine Beaupré wrote:
> Ideally, we'd process them in numeric order since that is more
> logical, but we can't do that yet since this is where we find the
> numeric identifiers in the first place. Lexicographic order is a good
> compromise.
The reader of this co
On Tue, Oct 31, 2017 at 02:50:06PM +0100, René Scharfe wrote:
> The path of a loose object contains its hash value encoded into two
> substrings of 2 and 38 hexadecimal digits separated by a slash. The
> first part is handed to for_each_file_in_obj_subdir() in decoded form as
> subdir_nr. The cu
On Sun, Oct 29, 2017 at 10:51 PM, Antoine Beaupré wrote:
> When we specify a list of namespaces to fetch from, by default the MW
> API will not fetch from the default namespace, refered to as "(Main)"
> in the documentation:
>
> https://www.mediawiki.org/wiki/Manual:Namespace#Built-in_namespaces
>
On Tue, Oct 31, 2017 at 02:49:56PM +0100, René Scharfe wrote:
> The path of a loose object contains its hash value encoded into two
> substrings of hexadecimal digits, separated by a slash. The current
> code copies the pieces into a temporary buffer to get rid of the slash
> and then uses get_oi
On Wed, Nov 1, 2017 at 7:50 PM, Jeff King wrote:
> The best workaround I could come up with is passing the output through a
> highlighting script:
>
> git log --grep=foo --color |
> perl -pe 's/foo/\x1b[1;31m$&\x1b[m/' |
> less
>
> Pretty hacky.
Thanks anyway. I was also considering someth
On Tue, Oct 31, 2017 at 2:49 PM, Eric Sunshine wrote:
>> to make up a name for the commit. These names are ambivalent, there might
>
> I guess you meant s/ambivalent/ambiguous/ ?
Indeed!
ambivalent
early 20th century: from ambivalence (from German Ambivalenz ),
on the pattern of equivalen
On Tue, Oct 31, 2017 at 10:54:21AM +0100, René Scharfe wrote:
> Reduce code duplication by extracting a function for rewriting an
> existing file.
These patches look like an improvement on their own, but I wonder if we
shouldn't just be using the existing write_file_buf() for this?
Compared to y
On Wed, Nov 1, 2017 at 5:37 AM, Junio C Hamano wrote:
> On Wed, Nov 1, 2017 at 9:26 PM, Johannes Schindelin
> wrote:
>>
>> ...
>> (
>> for x in four three
>> do
>> git rm $x &&
>> git commit -m "remote
Hi Peff,
On Wed, Nov 1, 2017 at 11:38 AM, Jeff King wrote:
> This was mostly done for the libgit2 project, which uses GPL with a
> linking exception:
>
> https://github.com/libgit2/libgit2/blob/master/COPYING
>
> When that project started, they asked for dual-license permission from
> various
Using 2.15.0 on OSX 10.12.6, when I open git gui, and then attempt to
stage multiple files as such:
* Left click first file
* CMD+Shift+Click last file to multi-select all files
* CMT+T (shortcut for Stage to Commit)
Only the file I selected with the first Left Click is staged and my
selection di
On Wed, Nov 01, 2017 at 11:57:14AM +0100, Sebastian Schuberth wrote:
> is there a way to colorize / highlight the pattern matched by
>
> git log -E -i --grep=pattern
>
> in the console output?
I don't think so. The grep code _does_ know about colorizing matches
(which is why "git grep --col
On Wed, Nov 01, 2017 at 08:50:00AM -0700, Elijah Newren wrote:
> Background: git's README.md file points out that some parts of git are
> under a license other than GPLv2 (while still GPLv2-compatible),
> though it doesn't state which one(s)
I think this note is mostly about code we've imported f
On Wed, Nov 1, 2017 at 8:50 AM, Elijah Newren wrote:
> Hi,
>
> My employer has a new-ish open-source-contribution process, and is
> curious about some licensing question(s) before I submit a few patch
> series.
cool. :)
> Background: git's README.md file points out that some parts of git are
> u
On Tue, Oct 31, 2017 at 6:21 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Signed-off-by: Stefan Beller
>> ---
>> t/t6120-describe.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Good. I am guessing that you are sending this as the last/optional
> one because this was
On Wed, Nov 1, 2017 at 4:04 AM, Matthieu Moy wrote:
> Junio C Hamano writes:
>
>> Payre Nathan writes:
>>
>>> From: Tom Russello
>>>
>>> ---
>>
>> Missing something here???
>
> To clarify for Nathan, Thimothee and Danial: the cover-letter is an
> introduction send before the patch series. It ca
>> Does the code describe a9dbc3f12c as v2.15.0:GIT-VERSION-GEN, or
>> would it always be :?
>
> As the blob is described using this function:
>
> static void process_object(struct object *obj, const char *path, void *data)
> {
>struct process_commit_data *pcd = data;
>
>if (!oidcmp
On Wed, 01 Nov 2017 10:21:20 +0900
Junio C Hamano wrote:
> Jeff Hostetler writes:
>
> >> Yes, that, together with the expectation that I will hear from both you
> >> and JTan
> >> once the result of combined effort becomes ready to replace this
> >> placeholder,
> >> matches my assumption.
> It sounds a bit stupid to cater to myself in patches *I* submit, but I
> refuse to believe that there are many people with more time on their hands
> than myself (last time I tried to research this, it looked as everybody
> has the same 86,400 seconds per day available, give or take the occasiona
On Tue, Oct 31, 2017 at 6:26 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> After some quick research our coding style on bit fields is twofold:
>> Most older code is this way and more recent code seems to prefer
>>
>> unsigned SP : SP ;
>
> Yes, we are very inconsistent. What does
This feature has been in Git for Windows since v2.11.0(2), as an
experimental option. Now it is considered mature, and it is high time to
document it properly.
Signed-off-by: Johannes Schindelin
---
Documentation/git.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Doc
Particularly when calling Git from applications, such as Visual Studio's
Team Explorer, it is important that stdin/stdout/stderr are closed
properly. However, when spawning processes on Windows, those handles
must be marked as inheritable if we want to use them, but that flag is a
global flag and m
Particularly when calling Git from applications, such as Visual Studio,
it is important that stdin/stdout/stderr are closed properly. However,
when spawning processes on Windows, those handles must be marked as
inheritable if we want to use them, but that flag is a global flag and
may very well be
The "2>&1" notation in Powershell and in Unix shells implies that stderr
is redirected to the same handle into which stdout is already written.
Let's use this special value to allow the same trick with
GIT_REDIRECT_STDERR and GIT_REDIRECT_STDOUT: if the former's value is
`2>&1`, then stderr will s
Am 01.11.2017 um 15:45 schrieb Simon Ruderich:
> Not checking close(2) can hide errors as not all errors are reported
> during the write(2).
>
> Signed-off-by: Simon Ruderich
> ---
>
> On Wed, Nov 01, 2017 at 02:00:11PM +0100, René Scharfe wrote:
>> Most calls are not checked, but that doesn't n
Hi Jonahtan,
On Tue, 31 Oct 2017, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
> > On Mon, 30 Oct 2017, Jonathan Nieder wrote:
>
> >> Can this rationale go in the commit messages?
> >
> > I thought I had done exactly that in 1/3...
>
> Okay, I'll be more specific. This cover letter incl
next_arg() returns NULL if it runs out of arguments. Most call sites
already handle that gracefully. Check in the remaining cases as well.
Replace the NULL pointer with an empty string at the bottom of
get_cmd_result() -- it's nicely reported as an unexpected response a
few lines down. Error out
On 2017-11-01 09:52:09, Eric Sunshine wrote:
> On Sun, Oct 29, 2017 at 10:51 PM, Antoine Beaupré wrote:
>> Virtual namespaces do not correspond to pages in the database and are
>> automatically generated by MediaWiki. It makes little sense,
>> therefore, to fetch pages from those namespaces and th
On Wed, Nov 1, 2017 at 12:14 AM, Jeff King wrote:
> On Mon, Oct 30, 2017 at 11:29:37AM -0700, Stefan Beller wrote:
>
>> > I can live with fancily-formatted cover letters. BUT. I would say if
>> > your cover letter is getting quite long, you might consider whether some
>> > of its content ought to
Hi Junio,
On Wed, 1 Nov 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> > +Two special values are supported: `off` will simply close the
> >> > +corresponding standard handle, and if `GIT_REDIRECT_STDERR` is
> >> > +`2>&1`, standard error will be redirected to the same handle a
Hi,
Bloomberg is hosting an Open Source Weekend in London on the 11th
& 12th November 2017 to contribute to the Git project. We have
also confirmed that Peff will be amongst the mentors on hand to
guide attendees through their efforts!
Some of you may notice that we tried to organize this earlie
Hi,
My employer has a new-ish open-source-contribution process, and is
curious about some licensing question(s) before I submit a few patch
series.
Background: git's README.md file points out that some parts of git are
under a license other than GPLv2 (while still GPLv2-compatible),
though it doe
Hi René,
On Tue, 31 Oct 2017, René Scharfe wrote:
> Cut off any previous content of the file to be rewritten by passing the
> flag O_TRUNC to open(2) instead of calling ftruncate(2) at the end.
> That's easier and shorter.
Sure.
Thanks,
Dscho
Hi René,
On Tue, 31 Oct 2017, René Scharfe wrote:
> Reduce code duplication by extracting a function for rewriting an
> existing file.
Fine by me. Thanks,
Dscho
Not checking close(2) can hide errors as not all errors are reported
during the write(2).
Signed-off-by: Simon Ruderich
---
On Wed, Nov 01, 2017 at 02:00:11PM +0100, René Scharfe wrote:
> Most calls are not checked, but that doesn't necessarily mean they need
> to (or should) stay that way. The
All other error messages in the file use quotes around the file name.
This change removes two translations as "could not write to '%s'" and
"could not close '%s'" are already translated and these two are the only
occurrences without quotes.
Signed-off-by: Simon Ruderich
---
wrapper.c | 8 --
On Sun, Oct 29, 2017 at 10:51 PM, Antoine Beaupré wrote:
> Virtual namespaces do not correspond to pages in the database and are
> automatically generated by MediaWiki. It makes little sense,
> therefore, to fetch pages from those namespaces and the MW API doesn't
> support listing those pages.
>
Am 01.11.2017 um 12:10 schrieb Simon Ruderich:
> On Tue, Oct 31, 2017 at 10:54:21AM +0100, René Scharfe wrote:
>> +static int rewrite_file(const char *path, const char *buf, size_t len)
>> +{
>> +int rc = 0;
>> +int fd = open(path, O_WRONLY);
>> +if (fd < 0)
>> +return error
On Wed, Nov 1, 2017 at 9:26 PM, Johannes Schindelin
wrote:
>
> ...
> (
> for x in four three
> do
> git rm $x &&
> git commit -m "remote $x" ||
> exit
> done
>
Hi Junio,
On Wed, 1 Nov 2017, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > +If the given object refers to a blob, it will be described
> > +as `:`, such that the blob can be found
> > +at `` in the ``. Note, that the commit is likely
>
> Does the code describe a9dbc3f12c as v2.15.0:GIT-
Hi,
On Wed, 1 Nov 2017, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > diff --git a/t/t6100-rev-list-in-order.sh b/t/t6100-rev-list-in-order.sh
> > new file mode 100755
> > index 00..651666979b
> > --- /dev/null
> > +++ b/t/t6100-rev-list-in-order.sh
> > @@ -0,0 +1,46 @@
> > +#!/bi
The static analysis job on Travis CI builds Git ever since it was
introduced in d8245bb3f (travis-ci: add static analysis build job to
run coccicheck, 2017-04-11). However, Coccinelle, the only static
analysis tool in use, only needs Git's source code to work and it
doesn't care about built Git bi
Linux build jobs on Travis CI skip the P4 and Git LFS tests since
commit 657343a60 (travis-ci: move Travis CI code into dedicated
scripts, 2017-09-10), claiming there are no P4 or Git LFS installed.
The reason is that P4 and Git LFS binaries are not installed to a
directory in the default $PATH, b
1 - 100 of 112 matches
Mail list logo