Am 27.02.2017 um 23:33 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Am 27.02.2017 um 21:04 schrieb Junio C Hamano:
>>> René Scharfe writes:
>>>
> diff --git a/apply.c b/apply.c
> index cbf7cc7f2..9219d2737 100644
> --- a/apply.c
> +++ b/apply.c
Hi,
On Mon, 27 Feb 2017, Junio C Hamano wrote:
> Jeff King writes:
>
> > The auto mode may incur an extra round-trip over setting
> > http.emptyauth=true, because part of the emptyauth hack is to feed
> > this blank password to curl even before we've made a single request.
>
>
On Mon, Feb 27, 2017 at 4:53 PM, Jeff King wrote:
> On Mon, Feb 27, 2017 at 04:33:36PM -0800, Junio C Hamano wrote:
>
>> A flag to affect the behaviour (as opposed to as a secondary
>> return value, like Peff's patch does) can be made to work. Perhaps
>> a flag that says "keep
On Mon, Feb 27, 2017 at 9:22 PM, Alexander Grigoriev
wrote:
> git version 2.10.2.windows.1:
> If a remote branch has never been checked out locally (its ref only exists
> in remotes// directory), "git worktree add" command is unable to
> check it out by its normal short
Signed-off-by: Patrick Steinhardt
---
Documentation/gitdiffcore.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index 46bc6d077..cf009a187 100644
--- a/Documentation/gitdiffcore.txt
+++
The gitdiffcore documentation quotes the term "Complete Rewrites" in
headers for no real gain. This would make sense if the term could be
easily confused if not properly grouped together. But actually, the term
is quite obvious and thus does not really need any quoting, especially
regarding that
On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote:
> One notable fallout of this patch series is that on 64-bit Linux (and
> other platforms where `unsigned long` is 64-bit), we now limit the range
> of dates to LONG_MAX (i.e. the *signed* maximum value). This needs to be
> done
On Mon, Feb 27, 2017 at 07:53:02PM -0500, Jeff King wrote:
> On Mon, Feb 27, 2017 at 04:33:36PM -0800, Junio C Hamano wrote:
>
> > A flag to affect the behaviour (as opposed to as a secondary
> > return value, like Peff's patch does) can be made to work. Perhaps
> > a flag that says "keep the
On Mon, Feb 27, 2017 at 11:09:12AM -0800, Stefan Beller wrote:
> For worktrees these multiple config files sounded like
> the obvious solution, but I wonder if there was also
> some bike shedding about other solutions?
>
> I could imagine that we would want to have attributes
> for specific
The return value from strbuf_branchname() is confusing and
useless: it's 0 if the whole name was consumed by an @-mark,
but otherwise is the length of the original name we fed.
No callers actually look at the return value, so let's just
get rid of it.
Signed-off-by: Jeff King
---
Hi Junio,
On Mon, 27 Feb 2017, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> - unsigned long number = strtoul(date, , 10);
> >> + time_t number = parse_timestamp(date, , 10);
> >
> > This hunk does not belong to this step. Everybody else in this step
>
>
This function asks strbuf_branchname() to expand any @-marks
in the branchname, and then we blindly stick refs/heads/ in
front of the result. This is obviously nonsense if the
expansion is "HEAD" or a ref in refs/remotes/.
The most obvious end-user effect is that creating or
renaming a branch
>From: ankostis [mailto:ankos...@gmail.com]
>Sent: February 28, 2017 8:01 AM
>To: Randall S. Becker
>Cc: Git Mailing List ; Jason Cooper
>Subject: Re: Unconventional roles of git
>On 27 February 2017 at 20:16, Randall S. Becker
When using git submodules, is there value in iterating about the git
submodules running "git verfiy-commit HEAD" or would that be already
covered by the git submodule verification?
Cheers,
Patrick
Hi Peff,
On Tue, 28 Feb 2017, Jeff King wrote:
> On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote:
>
> > One notable fallout of this patch series is that on 64-bit Linux (and
> > other platforms where `unsigned long` is 64-bit), we now limit the
> > range of dates to LONG_MAX
We generally put docstrings with function declarations,
because it's the callers who need to know how the function
works. Let's do so for interpret_branch_name().
Signed-off-by: Jeff King
---
cache.h | 21 +
sha1_name.c | 21 -
2 files
We use strbuf_branchname() to expand the branch name from
the command line, so you can delete the branch given by
@{-1}, for example. However, we allow other nonsense like
"@", and we do not respect our "-r" flag (so we may end up
deleting an oddly-named local ref instead of a remote one).
We
Hi Junio,
On Mon, 27 Feb 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > One notable fallout of this patch series is that on 64-bit Linux (and
> > other platforms where `unsigned long` is 64-bit), we now limit the
> > range of dates to LONG_MAX (i.e.
On Tue, Feb 28, 2017 at 07:14:34AM -0500, Jeff King wrote:
> However, out-parameters make calling interface somewhat
> cumbersome. Instead, let's do the opposite: let the caller
> tell us which elements to expand. That's easier to pass in,
> and none of the callers give more precise error
git-branch feeds the branch names from the command line to
strbuf_branchname(), but we do not yet tell that function
which kinds of expansions should be allowed. Let's create a
set of tests that cover both the allowed and disallowed
cases.
That shows off some breakages where we currently create
On Mon, Feb 27, 2017 at 06:53:11PM -0800, Jonathan Tan wrote:
> http.c supports HTTP redirects of the form
>
> http://foo/info/refs?service=git-upload-pack
> -> http://anything
> -> http://bar/info/refs?service=git-upload-pack
>
> (that is to say, as long as the Git part of the path and
When we parse "git checkout $NAME", we try to interpret
$NAME as a local branch-name. If it is, then we point HEAD
to that branch. Otherwise, we detach the HEAD at whatever
commit $NAME points to.
We do the interpretation by calling strbuf_branchname(), and
then blindly sticking "refs/heads/" on
On Tue, Feb 28, 2017 at 09:59:05AM +0100, Patrick Steinhardt wrote:
> The gitdiffcore documentation quotes the term "Complete Rewrites" in
> headers for no real gain. This would make sense if the term could be
> easily confused if not properly grouped together. But actually, the term
> is quite
On Tue, Feb 28, 2017 at 07:23:38AM -0500, Jeff King wrote:
> > -int interpret_branch_name(const char *name, int namelen, struct strbuf
> > *buf)
> > +int interpret_branch_name(const char *name, int namelen, struct strbuf
> > *buf,
> > + unsigned allowed)
> > {
> > char
On Tue, Feb 28, 2017 at 01:24:10AM +, Ramsay Jones wrote:
> The last caller of git_mkstemp() was removed in commit 6fec0a89
> ("verify_signed_buffer: use tempfile object", 16-06-2016). Since
> the introduction of the 'tempfile' APIs, along with git_mkstemp_mode,
> it is unlikely that new
This function and its companion, strbuf_check_branch_ref(),
did not have their purpose or semantics explained. Let's do
so.
Signed-off-by: Jeff King
---
strbuf.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/strbuf.h b/strbuf.h
index 47df0500d..6b51b2604
The original purpose of interpret_branch_name() was to be
used by get_sha1() in resolving refs. As such, some of its
expansions may point to refs outside of the local
"refs/heads" namespace.
Over time, the function has been picked up by other callers
who want to use the ref-expansion to give the
On Mon, Feb 27, 2017 at 02:29:18PM +0100, René Scharfe wrote:
> Am 25.02.2017 um 20:04 schrieb brian m. carlson:
> >>> So I think that the current scope left is best estimated by the
> >>> following command:
> >>>
> >>> git grep -P 'unsigned char\s+(\*|.*20)' | grep -v '^Documentation'
> >>>
>
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> git_path() and friends are going to be killed in files-backend.c in near
> future. And because there's a risk with overwriting buffer in
> git_path(), let's convert them all to strbuf_git_path(). We'll have
> easier time killing/converting
Hello,
I noticed that the --subject-prefix string gets truncated sometimes,
but only when using the --numbered flat. Here's an example:
addu@sestofb11:/data/fb/addu/git$ export longm="very very very very
very very very very very very very very very very long prefix"
Am 28.02.2017 um 15:28 schrieb Jeff King:
On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote:
One notable fallout of this patch series is that on 64-bit Linux (and
other platforms where `unsigned long` is 64-bit), we now limit the range
of dates to LONG_MAX (i.e. the *signed*
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> Keep repo-related path handling in one place. This will make it easier
> to add submodule/multiworktree support later.
>
> This automatically adds the "if submodule then use the submodule version
> of git_path" to other call sites too. But it
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> refs.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 81b64b4ed..dab1a21ac 100644
> --- a/refs.c
> +++
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> get_ref_store() will soon be renamed to get_submodule_ref_store().
> Together with future get_worktree_ref_store(), the three functions
> provide an appropriate ref store for different operation modes. New APIs
> will be added to operate
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> This makes reflog path building consistent, always in the form of
>
> strbuf_git_path(sb, "logs/%s", refname);
>
> It reduces the mental workload a bit in the next patch when that
> function call is converted.
>
> Signed-off-by: Nguyễn
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> t/t1406-submodule-ref-store.sh (new +x) | 95
> +
> 1 file changed, 95 insertions(+)
> create mode 100755 t/t1406-submodule-ref-store.sh
>
>
Patrick Steinhardt writes:
> Signed-off-by: Patrick Steinhardt
> ---
> Documentation/gitdiffcore.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
> index
Patrick Schleizer writes:
> When using git submodules, is there value in iterating about the git
> submodules running "git verfiy-commit HEAD" or would that be already
> covered by the git submodule verification?
That depends on what you are referring to with
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> Given $GIT_DIR and $GIT_COMMON_DIR, files-backend is now in charge of
> deciding what goes where (*). The end goal is to pass $GIT_DIR only. A
> refs "view" of a linked worktree is a logical ref store that combines
> two files backends
On 2017-02-27 21:17, Junio C Hamano wrote:
> Torsten, you've been quite active in fixing various glitches around
> the EOL conversion in the latter half of last year. Have any
> thoughts to share on this topic?
>
> Thanks.
Sorry for the delay, being too busy with other things.
I followed the
Hello,
Hello, how are you doing? I want to inform you that, we have an
inheritance of a deceased client with your surname. Reply via email:
andrsi...@yandex.com with your full names for info.
Regards.
Miss. Melissa.
--
Correo Corporativo Hospital
Jeff King writes:
> I do not just agree, but I think the move to a signed timestamp is a big
> improvement. Git's object format is happy to represent times before
> 1970, but the code is not. I know this has been a pain for people who
> import ancient histories into Git.
>
> It
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> This is the last function in this code (besides public API) that takes
> submodule argument and handles both main/submodule cases. Break it down,
> move main store registration in get_main_ref_store() and keep the rest
> in
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> v5 goes a bit longer than v4, basically:
I've read through patch 14/24 so far, and they all look good except for
the mostly superficial comments that I have sent so far. I like the way
this is heading!
I'll try to continue tomorrow.
Michael
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> refs is learning to avoid path rewriting that is done by
> strbuf_git_path_submodule(). Factor out this code so it could be reused
> by refs*
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> path.c | 34
On Tue, Feb 28, 2017 at 10:55:49AM -0800, Junio C Hamano wrote:
> > Glibc will get a way to enable 64-bit time_t on 32-bit platforms
> > eventually
> > (https://sourceware.org/glibc/wiki/Y2038ProofnessDesign). Can
> > platforms that won't provide a 64-bit time_t by 2038 be actually used
> > at
On Tue, Feb 28, 2017 at 12:27:45PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > The original purpose of interpret_branch_name() was to be used by
> > get_sha1() in resolving refs. As such, some of its expansions may
> > point to refs outside of the local "refs/heads"
Junio C Hamano writes:
> Adrian Dudau writes:
>
>> I noticed that the --subject-prefix string gets truncated sometimes,
>> but only when using the --numbered flat. Here's an example:
>>
>> addu@sestofb11:/data/fb/addu/git$ export longm="very very very
On Tue, Feb 28, 2017 at 10:05:24AM -0800, Stefan Beller wrote:
> > I have a feeling that something like this would create unwelcome corner
> > cases in the config-writer, which is otherwise does not have to care
> > about which existing section of a file it adds a key to.
>
> Yeah the writer
On Tue, Feb 28, 2017 at 09:26:23AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I do not just agree, but I think the move to a signed timestamp is a big
> > improvement. Git's object format is happy to represent times before
> > 1970, but the code is not. I know this
Now that stash_push is used in the no verb form of stash, allow
specifying the command line for this form as well. Always use -- to
disambiguate pathspecs from other non-option arguments.
Also make git stash -p an alias for git stash push -p. This allows
users to use git stash -p .
While working on a repository, it's often helpful to stash the changes
of a single or multiple files, and leave others alone. Unfortunately
git currently offers no such option. git stash -p can be used to work
around this, but it's often impractical when there are a lot of changes
over multiple
On Tue, Feb 28, 2017 at 11:53 AM, Junio C Hamano wrote:
> Linus Torvalds writes:
>>
>> Having the hashes be more encapsulated does seem to make things better
>> in many ways. What I did was to also just unify the notion of "hash_t"
>> and "struct
Thanks Junio for the review and the squashable diff with the fix for
my errors.
I changed it a tiny bit, to use git stash push instead of git stash,
so the complete diff could go into 4/6, where I think I think the test
fits best.
Interdiff below:
diff --git a/git-stash.sh b/git-stash.sh
index
Currently there is no test showing the expected behaviour of git stash
create's command line arguments. Add a test for that to show the
current expected behaviour and to make sure future refactorings don't
break those expectations.
Signed-off-by: Thomas Gummerer
---
Hi Junio,
On Tue, 28 Feb 2017, Junio C Hamano wrote:
> René Scharfe writes:
>
> > Am 28.02.2017 um 15:28 schrieb Jeff King:
> >
> >> It looks from the discussion like the sanest path forward is our own
> >> signed-64bit timestamp_t. That's unfortunate compared to using the
> >>
[Responses inline]
No need to keep me "bcc'd" (though thanks for the consideration) -- I'm happy
to ignore anything I don't want to be pulled into ;-)
Here's a rollup of what needs to be done based on the discussion below:
1) Remove extraneous exports from sha1.h
2) Remove "safe mode" support.
Thomas Gummerer writes:
> + git reset ${GIT_QUIET:+-q} -- "$@"
> + git ls-files -z --modified -- "$@" |
> + git checkout-index -z --force --stdin
> + git checkout ${GIT_QUIET:+-q} HEAD -- $(git
Jeff King writes:
> The original purpose of interpret_branch_name() was to be used by
> get_sha1() in resolving refs. As such, some of its expansions may
> point to refs outside of the local "refs/heads" namespace.
I am not sure the reference to "get_sha1()" is entirely correct.
On Tue, Feb 28, 2017 at 4:06 AM, Jeff King wrote:
> On Mon, Feb 27, 2017 at 07:53:02PM -0500, Jeff King wrote:
>
>> On Mon, Feb 27, 2017 at 04:33:36PM -0800, Junio C Hamano wrote:
>>
>> > A flag to affect the behaviour (as opposed to as a secondary
>> > return value, like Peff's
Michael Haggerty writes:
> On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
>> v5 goes a bit longer than v4, basically:
>
> I've read through patch 14/24 so far, and they all look good except for
> the mostly superficial comments that I have sent so far. I like the way
>
On Tue, Feb 28, 2017 at 10:48:52AM -0800, Jonathan Tan wrote:
> > Running your included test, we get:
> >
> > fatal: unable to access 'http://127.0.0.1:5550/redir-to/502/': The
> > requested URL returned error: 502
> >
> > but the error really happened in the intermediate step. I wonder if
On 02/27, René Scharfe wrote:
> Am 27.02.2017 um 19:22 schrieb Brandon Williams:
> >On 02/25, René Scharfe wrote:
> >>+void strbuf_add_real_path(struct strbuf *sb, const char *path)
> >>+{
> >>+ if (sb->len) {
> >>+ struct strbuf resolved = STRBUF_INIT;
> >>+
On Tue, Feb 28, 2017 at 08:33:13PM +, brian m. carlson wrote:
> On Tue, Feb 28, 2017 at 03:26:34PM -0500, Jeff King wrote:
> > Yeah, a lot of brian's patches have been focused around the fixing the
> > related size assumptions. We've got GIT_SHA1_HEXSZ which doesn't solve
> > the problem, but
On Mon, Feb 27, 2017 at 10:59:15PM -0800, Linus Torvalds wrote:
> I saw that somebody is actually looking at doing this "well" - by
> doing it in many smaller steps. I tried. I gave up. The "unsigned char
> *sha1" model is so ingrained that doing it incrementally just seemed
> like a lot of pain.
Introduce a new git stash push verb in addition to git stash save. The
push verb is used to transition from the current command line arguments
to a more conventional way, in which the message is given as an argument
to the -m option.
This allows us to have pathspecs at the end of the command
On Tue, Feb 28, 2017 at 03:26:34PM -0500, Jeff King wrote:
> Yeah, a lot of brian's patches have been focused around the fixing the
> related size assumptions. We've got GIT_SHA1_HEXSZ which doesn't solve
> the problem, but at least makes it easy to find. And a big improvement
> in the most recent
Refactor the internal stash_create function to use a -m flag for
specifying the message and -u flag to indicate whether untracked files
should be added to the stash.
This makes it easier to pass a pathspec argument to stash_create in the
next patch.
The user interface for git stash create stays
Hi,
On Tue, 28 Feb 2017, w...@cornell.edu wrote:
> I have attempted to download the new version but on 2/28/2016 starting
> at 12:00PM EST I have been unable to download GIT 2.12. The error
> message that is returned is:
>
> Make sure you’ve got the right web address:
>
Brandon Williams writes:
> /* Add super prefix */
> + quote_path_relative(name, opt->prefix, );
Hmph, do you want a quoted version here, not just relative_path()?
Perhaps add a test with an "unusual" byte (e.g. a double-quote) in
the path?
>
Hi,
On Tue, 28 Feb 2017, Johannes Schindelin wrote:
> When Git v2.9.1 was released, it had a bug that showed only on Windows
> and on 32-bit systems: our assumption that `unsigned long` can hold
> 64-bit values turned out to be wrong.
>
> This could have been caught earlier if we had a
Am 28.02.2017 um 21:51 schrieb Junio C Hamano:
> Andreas Heiduk writes:
>
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index e6215c3..7c28e73 100644
>> --- a/Documentation/diff-options.txt
>> +++ b/Documentation/diff-options.txt
>> @@
Andreas Heiduk writes:
> I'll fix the "munged" and, unless there are objections, I will also
> replace the remaining ones in the vicinity. These are the last
> occurrences of "munged".
I'd rather see the "we do not munge" to stay the same. "we do not
quote" still allows us
Am 24.02.2017 um 22:54 schrieb Jakub Narębski:
> W dniu 24.02.2017 o 21:37, Andreas Heiduk pisze:
>> Linking the description for pathname quoting to the configuration
>> variable "core.quotePath" removes inconstistent and incomplete
>> sections while also giving two hints how to deal with it:
On Tue, Feb 28, 2017 at 09:54:58PM +0100, Johannes Schindelin wrote:
> > Right now, they may be able to have future timestamps ranging to
> > year 2100 and switching to time_t would limit their ability to
> > express future time to 2038 but they would be able to express
> > timestamp in the past
On Tue, Feb 28, 2017 at 12:25:20PM -0800, Linus Torvalds wrote:
> On Tue, Feb 28, 2017 at 11:53 AM, Junio C Hamano wrote:
> > Sorry, but at this point in your description, you completely lost
> > me. I thought "struct object_id" was what you call "hash_t" in the
> > above.
>
Jonathan Tan writes:
> When the --objects argument is given to rev-list, an argument of the
> form "^$tree" can be given to exclude all blobs and trees reachable from
> that tree, but an argument of the form "^$commit" only excludes that
> commit, not any blob or tree
On Tue, Feb 28, 2017 at 01:42:44PM -0800, Junio C Hamano wrote:
> Jonathan Tan writes:
>
> > It could be argued that in the future, Git might need to distinguish
> > tree_objects from blob_objects - in particular, a user might want
> > rev-list to print the trees but
Torsten Bögershausen writes:
> On 2017-02-27 21:17, Junio C Hamano wrote:
>
>> Torsten, you've been quite active in fixing various glitches around
>> the EOL conversion in the latter half of last year. Have any
>> thoughts to share on this topic?
>>
>> Thanks.
>
> Sorry for the
Am 24.02.2017 um 22:43 schrieb Jakub Narębski:
> W dniu 24.02.2017 o 21:37, Andreas Heiduk pisze:
>> Signed-off-by: Andreas Heiduk
>
> Thanks. This is good work.
:-)
>
>> ---
>> Documentation/config.txt | 24 ++--
>> 1 file changed, 14 insertions(+),
On Fri, Feb 24, 2017 at 05:18:37PM -0800, Jonathan Tan wrote:
> When the --objects argument is given to rev-list, an argument of the
> form "^$tree" can be given to exclude all blobs and trees reachable from
> that tree, but an argument of the form "^$commit" only excludes that
> commit, not any
On Tue, Feb 28, 2017 at 12:08 PM, Jeff King wrote:
> On Tue, Feb 28, 2017 at 10:05:24AM -0800, Stefan Beller wrote:
>
>> > I have a feeling that something like this would create unwelcome corner
>> > cases in the config-writer, which is otherwise does not have to care
>> > about
Andreas Heiduk writes:
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index e6215c3..7c28e73 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -192,10 +192,9 @@ ifndef::git-log[]
> given, do not
Brandon Williams writes:
> Fix a bug which causes a child process for a submodule to error out when a
> relative pathspec with a ".." is provided in the superproject.
>
> While at it, correctly construct the super-prefix to be used in a submodule
> when not at the root of the
On Tue, Feb 28, 2017 at 12:21:57PM -0800, Stefan Beller wrote:
> > I'm still open to the idea that we simply improve the documentation to
> > make it clear that per-repo config really is per-repo, and is not shared
> > between super-projects and submodules. And then something like Duy's
> >
Jonathan Tan writes:
> It could be argued that in the future, Git might need to distinguish
> tree_objects from blob_objects - in particular, a user might want
> rev-list to print the trees but not the blobs.
That was exactly why these bits were originally made to
On Mon, Feb 27, 2017 at 01:00:01PM +, Ian Jackson wrote:
> I said I was working on a transition plan. Here it is. This is
> obviously a draft for review, and I have no official status in the git
> project. But I have extensive experience of protocol compatibility
> engineering, and I hope
Now that we have stash_push, which accepts pathspec arguments, use
it instead of stash_save in git stash without any additional verbs.
Previously we allowed git stash -- -message, which is no longer allowed
after this patch. Messages starting with a hyphen was allowed since
3c2eb80f, ("stash:
On Tue, Feb 28, 2017 at 03:59:16PM +, Adrian Dudau wrote:
> This is happening on the latest master branch, so I dug through the
> code and tracked the issue to this piece of code in log-tree.c:
>
> if (opt->total > 0) {
> static char buffer[64];
>
On Fri, Feb 24, 2017 at 05:18:36PM -0800, Jonathan Tan wrote:
> Whenever tree_objects is set to 1 in revision.h's struct rev_info,
> blob_objects is likewise set, and vice versa. Combine those two fields
> into one.
>
> Some of the existing code does not handle tree_objects being different
>
On Tue, Feb 28, 2017 at 02:27:22PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... We can certainly stick with it for now (it's awkward if you
> > really do have an entry on Jan 1 1970, but other than that it's an OK
> > marker). I agree that the most negatively value
From: Linus Torvalds
Date: Tue, 28 Feb 2017 16:12:32 -0800
Subject: [PATCH] Put sha1dc on a diet
This removes the unnecessary parts of the sha1dc code, shrinking things from
[torvalds@i7 git]$ size sha1dc/*.o
textdata bss dec
Jeff King writes:
> ... We can certainly stick with it for now (it's awkward if you
> really do have an entry on Jan 1 1970, but other than that it's an OK
> marker). I agree that the most negatively value is probably a saner
> choice, but we can switch to it after the dust
On Tue, Feb 28, 2017 at 11:33:55AM -0800, Junio C Hamano wrote:
> And having said all that, if we really want to allow overlong
> subject prefix that would end up hiding the real title of the patch,
> a modern way to do so would be to use xstrfmt() like the attached
> toy-patch does.
If you are
On Tue, Feb 28, 2017 at 11:52 AM, Shawn Pearce wrote:
>
>> and from what I can tell, the 'maski' value is always 0, so the
>> looping over 80 state masks is really just a loop over two.
>
> Actually, look closer at that loop:
No, sorry, I wasn't clear and took some shortcuts
Hi René,
On Tue, 28 Feb 2017, René Scharfe wrote:
> Am 28.02.2017 um 21:54 schrieb Johannes Schindelin:
> >
> > On Tue, 28 Feb 2017, Junio C Hamano wrote:
> >
> > > René Scharfe writes:
> > >
> > > > Am 28.02.2017 um 15:28 schrieb Jeff King:
> > > >
> > > > > It looks from the
On Tue, Feb 28, 2017 at 11:53:28AM -0800, Junio C Hamano wrote:
> Linus Torvalds writes:
>
> > That
> > actually can clean up some code, because right now we have duplicate
> > interfaces for some things that take an oid pointer and others take a
> > "const
On Tue, Feb 28, 2017 at 2:50 PM, Marc Stevens wrote:
>
> Because we only have 32 disturbance vectors to check, we have DVMASKSIZE
> equal to 1 and maski always 0.
> In the more general case when we add disturbance vectors this will not
> remain the case.
Ok, I didn't get why
Am 01.03.2017 um 00:10 schrieb Johannes Schindelin:
Hi René,
On Tue, 28 Feb 2017, René Scharfe wrote:
Am 28.02.2017 um 21:54 schrieb Johannes Schindelin:
On Tue, 28 Feb 2017, Junio C Hamano wrote:
René Scharfe writes:
Am 28.02.2017 um 15:28 schrieb Jeff King:
It looks
You can also keep me in this thread, so we can help or answer any
further questions,
but I also appreciate the feedback on our project.
Like Dan Shumow said, our main focus on the library has been correctness
and then performance.
The entire files ubc_check.c and ubc_check.h are generated based
1 - 100 of 113 matches
Mail list logo