In an update to fix a bug with "commit --dry-run" it was found that
the commitable flag was broken. The update was, at the time,
accepted as it was better than the previous version.
Since the set of the flag had been done in wt_longstatus_print_updated,
set the flag in
Two tests were written which showed failure cases when passing
--procelain or --short.
Change the test to expect success since updates to the wt-status
broken code section is being fixed.
Signed-off-by: Stephen P. Smith
---
t/t7501-commit.sh | 4 ++--
1 file changed, 2 insertions(+), 2
A couple of years ago, during a patch review Junio found that the
commitable bit as implemented in wt-status.c was broken.
Stephen P. Smith (3):
Change tests from expecting to fail to expecting success.
Add test for commit --dry-run --short.
wt-status.c: Set the commitable flag in the
Add test for commit with --dry-run --short for a new file of zero
length.
The test demonstrated that the setting of the commitable flag was
broken as was found durning an earlier patch review.
Signed-off-by: Stephen P. Smith
---
t/t7501-commit.sh | 10 ++
1 file changed, 10
Hi,
Torsten Bögershausen wrote:
> My original plan was to try to "make obsolete"/retire
> and phase out core.autocrlf completely.
> However, since e.g. egit/jgit uses it
> (they don't have support for .gitattributes at all) I am not sure if this
> is a good idea either.
Interesting. [1]
Ævar Arnfjörð Bjarmason wrote:
> There is interest in this. This E-Mail of mine gives a good summary of
> prior discussions about this:
> https://public-inbox.org/git/877eqqnq22@evledraar.gmail.com/
>
> I.e. it's something I've personally been interested in doing in the
> past, there's
Eric Wong wrote:
> Jonathan Nieder wrote:
>> Jeff King wrote:
>>> I guess I just wonder if I set up a mirror on another domain, would
>>> anybody actually _use_ it? I'd think most people would just go to
>>> public-inbox.org as the de facto URL.
>>
>> If it's faster than public-inbox.org and you
On Fri, Aug 31, 2018 at 12:49:39AM +0100, Ramsay Jones wrote:
> On 30/08/18 21:14, Junio C Hamano wrote:
> > Jeff King writes:
> >
> >> I suppose so. I don't think I've _ever_ used distclean, and I only
> >> rarely use "clean" (a testament to our Makefile's efforts to accurately
> >> track
On 30/08/18 21:14, Junio C Hamano wrote:
> Jeff King writes:
>
>> I suppose so. I don't think I've _ever_ used distclean, and I only
>> rarely use "clean" (a testament to our Makefile's efforts to accurately
>> track dependencies). I'd usually use "git clean" when I want something
>> pristine
On Thu, Aug 30 2018, Ævar Arnfjörð Bjarmason wrote:
[Notes to self]
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 55277a9781..0f03d36f1e 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -74,12 +74,41 @@ without any `` on the
On Thu, Aug 30 2018, Paul-Sebastian Ungureanu wrote:
> Hello,
>
> This a new iteration of `stash.c`. What is new?
>
> * Some commits got squashed. The commit related to replacing
> `git apply` child process was dropped since it wasn't the best
> idea.
>
> * In v7, there was a bug [1]
Paul-Sebastian Ungureanu writes:
> Removed whitespaces after redirection operators.
A clean-up that is long overdue. Thanks.
The result still has some rooms to improve (e.g. the preparation of
'expect' file probably should be done in a test_expect_success block
of the setup step; some are
Paul-Sebastian Ungureanu writes:
> This commit introduces tests for `git stash show`
> config. It tests all the cases where `stash.showStat`
> and `stash.showPatch` are unset or set to true / false.
>
> Signed-off-by: Paul-Sebastian Ungureanu
> ---
> t/t3907-stash-show-config.sh | 81
Ævar Arnfjörð Bjarmason writes:
> +
> -Unlike when pushing with linkgit:git-push[1], any updates to
> -`refs/tags/*` will be accepted without `+` in the refspec (or
> -`--force`). The receiving promiscuously considers all tag updates from
> -a remote to be forced fetches.
> +Until Git version
Add stash store to the helper and delete the store_stash function
from the shell script.
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash--helper.c | 55 +
git-stash.sh| 43 ++--
2 files changed, 57
Add stash create to the helper.
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash--helper.c | 430
git-stash.sh| 2 +-
2 files changed, 431 insertions(+), 1 deletion(-)
diff --git a/builtin/stash--helper.c b/builtin/stash--helper.c
Add stash save to the helper and delete functions which are no
longer needed (`show_help()`, `save_stash()`, `push_stash()`,
`create_stash()`, `clear_stash()`, `untracked_files()` and
`no_changes()`).
The `-m` option is no longer supported as it might not make
sense to have two ways of passing a
There is a change in behaviour with this commit. When there was
no initial commit, the shell version of stash would still display
a message. This commit makes `push` to not display any message if
`--quiet` or `-q` is specified.
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash--helper.c
The old shell script `git-stash.sh` was removed and replaced
entirely by `builtin/stash.c`. In order to do that, `create` and
`push` were adapted to work without `stash.sh`. For example, before
this commit, `git stash create` called `git stash--helper create
--message "$*"`. If it called `git
This commit replaces spawning `git write-tree` with API calls.
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash.c | 41 -
1 file changed, 12 insertions(+), 29 deletions(-)
diff --git a/builtin/stash.c b/builtin/stash.c
index
This commits introduces a optimization by avoiding calling the
same functions again. For example, `git stash push -u`
would call at some points the following functions:
* `check_changes()` (inside `do_push_stash()`)
* `do_create_stash()`, which calls: `check_changes()` and
Add stash push to the helper.
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash--helper.c | 229
git-stash.sh| 6 +-
2 files changed, 233 insertions(+), 2 deletions(-)
diff --git a/builtin/stash--helper.c b/builtin/stash--helper.c
From: Joel Teichroeb
Add the drop and clear commands to the builtin helper. These two
are each simple, but are being added together as they are quite
related.
We have to unfortunately keep the drop and clear functions in the
shell script as functions are called with parameters internally
that
Rename some test cases' labels to be more descriptive and under 80
characters per line.
Signed-off-by: Paul-Sebastian Ungureanu
---
t/t3903-stash.sh | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index
From: Joel Teichroeb
Add stash branch to the helper and delete the apply_to_branch
function from the shell script.
Checkout does not currently provide a function for checking out
a branch as cmd_checkout does a large amount of sanity checks
first that we require here.
Signed-off-by: Joel
This commit introduces tests for `git stash show`
config. It tests all the cases where `stash.showStat`
and `stash.showPatch` are unset or set to true / false.
Signed-off-by: Paul-Sebastian Ungureanu
---
t/t3907-stash-show-config.sh | 81
1 file changed, 81
Removed whitespaces after redirection operators.
Signed-off-by: Paul-Sebastian Ungureanu
---
t/t3903-stash.sh | 120 ---
1 file changed, 61 insertions(+), 59 deletions(-)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index af7586d43d..de6cab1fe7
From: Joel Teichroeb
In preparation for converting the stash command incrementally to
a builtin command, this patch improves test coverage of the option
parsing. Both for having too many parameters, or too few.
Signed-off-by: Joel Teichroeb
Signed-off-by: Paul-Sebastian Ungureanu
---
Hello,
This a new iteration of `stash.c`. What is new?
* Some commits got squashed. The commit related to replacing
`git apply` child process was dropped since it wasn't the best
idea.
* In v7, there was a bug [1] related to config `git stash show`
The bug was fixed and a test file was
From: Joel Teichroeb
Add a builtin helper for performing stash commands. Converting
all at once proved hard to review, so starting with just apply
lets conversion get started without the other commands being
finished.
The helper is being implemented as a drop in replacement for
stash so that
Compared to `get_oid()`, `get_oidf()` has as parameters
a pointer to `object_id`, a printf format string and
additional arguments. This will help simplify the code
in subsequent commits.
Original-idea-by: Johannes Schindelin
Signed-off-by: Paul-Sebastian Ungureanu
---
cache.h | 1 +
From: Joel Teichroeb
Add stash pop to the helper and delete the pop_stash, drop_stash,
assert_stash_ref functions from the shell script now that they
are no longer needed.
Signed-off-by: Joel Teichroeb
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash--helper.c | 36
Add stash show to the helper and delete the show_stash, have_stash,
assert_stash_like, is_stash_like and parse_flags_and_rev functions
from the shell script now that they are no longer needed.
In shell version, although `git stash show` accepts `--index` and
`--quiet` options, it ignores them. In
Add stash list to the helper and delete the list_stash function
from the shell script.
Signed-off-by: Paul-Sebastian Ungureanu
---
builtin/stash--helper.c | 31 +++
git-stash.sh| 7 +--
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git
Mention in the usage text and in the documentation, that `show`
accepts any option known to `git diff`.
Signed-off-by: Paul-Sebastian Ungureanu
---
Documentation/git-stash.txt | 4 ++--
builtin/stash--helper.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Ævar Arnfjörð Bjarmason writes:
> +on the remote side. Whether this is allowed depends on where in
> +`refs/*` the reference lives as described in detail below. Any
> +such update does *not* attempt to merge into . See EXAMPLES
> +below for details.
> ++
> +The `refs/heads/*` namespace will
Ævar Arnfjörð Bjarmason writes:
> The test suite only incidentally (and unintentionally) tested for the
> current behavior of eager tag clobbering on "fetch". This is a
> followup to 380efb65df ("push tests: assert re-pushing annotated
> tags", 2018-07-31) which tests for it explicitly.
>
>
Ævar Arnfjörð Bjarmason writes:
> The quoted -m'msg' option is passed as a string to another function,
> where due to interpolation it'll end up meaning the same as if we did
> just did -m'msg' here.
"as if we did just did"? Also the sentence says -m'msg' is treated
as if we gave -m'msg' that
On Thu, Aug 30 2018, Jeff King wrote:
> On Thu, Aug 30, 2018 at 01:29:53PM -0700, Junio C Hamano wrote:
>
>> >> > I do not know if the documentation that is shipped in 2.20 should
>> >> > talk about how the old world looked like, though. `-l` was a short
>> >> > for `--create-reflog` is worth
On Thu, Aug 30, 2018 at 04:34:43PM -0400, Eric Sunshine wrote:
> On Thu, Aug 30, 2018 at 3:55 PM Jeff King wrote:
> > The tmp-doc-diff directory isn't strictly a build product of
> > the Makefile, since it's only present if you manually run
> > the doc-diff script. But anybody running "make
On Thu, Aug 30, 2018 at 01:29:53PM -0700, Junio C Hamano wrote:
> >> > I do not know if the documentation that is shipped in 2.20 should
> >> > talk about how the old world looked like, though. `-l` was a short
> >> > for `--create-reflog` is worth saying, but I do not see much value
> >> > in
On Thu, Aug 30, 2018 at 4:34 PM Eric Sunshine wrote:
> Taking into consideration that people might be surprised and alarmed
> to find "git worktree list" showing a worktree they didn't explicitly
> create, would it make sense to do something like this?
>
> clean:
> ...
> -git worktree
On Thu, Aug 30, 2018 at 3:55 PM Jeff King wrote:
> The tmp-doc-diff directory isn't strictly a build product of
> the Makefile, since it's only present if you manually run
> the doc-diff script. But anybody running "make clean" would
> probably want it to go away.
>
> Suggested-by: Eric Sunshine
Jeff King writes:
> On Thu, Aug 30, 2018 at 09:53:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > In the SYNOPSIS section we still see "[-l]" listed; that also must
>> > be replaced with "--create-reflog", or just dropped, as that is the
>> > default.
>>
>> Oh yes, it seems all of the doc
Jeff King writes:
> I suppose so. I don't think I've _ever_ used distclean, and I only
> rarely use "clean" (a testament to our Makefile's efforts to accurately
> track dependencies). I'd usually use "git clean" when I want something
> pristine (because I don't want to trust the Makefile at
Change "fetch" to treat "+" in refspecs (aka --force) to mean we
should clobber a local tag of the same name.
This changes the long-standing behavior of "fetch" added in
853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20). Before this
change, all tag fetches effectively had --force enabled. See
There's complex rules governing whether a push is allowed to take
place depending on whether we're pushing to refs/heads/*, refs/tags/*
or refs/not-that/*. See is_branch() in refs.c, and the various
assertions in refs/files-backend.c. (e.g. "trying to write non-commit
object %s to branch '%s'").
Refer to the new git-push(1) documentation about when ref updates are
and aren't allowed with and without --force, noting how "git-fetch"
differs from the behavior of "git-push".
Perhaps it would be better to split this all out into a new
gitrefspecs(7) man page, or present this information using
The test suite only incidentally (and unintentionally) tested for the
current behavior of eager tag clobbering on "fetch". This is a
followup to 380efb65df ("push tests: assert re-pushing annotated
tags", 2018-07-31) which tests for it explicitly.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
The quoted -m'msg' option is passed as a string to another function,
where due to interpolation it'll end up meaning the same as if we did
just did -m'msg' here.
In [1] this was pointed out to me, but in submitting [2] the patches I
missed this (since it was feedback on another patch I was
Now that the tests for this have landed in master (in v3), and because
I needed to rebase these for rolling out my own version based on
v2.19.0-rc1, here's a re-roll which should address the (mostly doc)
comments on the previous (v2) round.
Ævar Arnfjörð Bjarmason (6):
fetch: change "branch" to
The -h output has been referring to the --force command as forcing the
overwriting of local branches, but since "fetch" more generally
fetches all sorts of references in all refs/ namespaces, let's talk
about forcing the update of a a "reference" instead.
This wording was initially introduced in
On Thu, Aug 30, 2018 at 01:03:41PM +0200, Johannes Schindelin wrote:
> > Will replace by doing:
> >
> > $ git checkout js/rebase-in-c-5.5-work-with-rebase-i-in-c
> > $ git checkout HEAD^
> > $ git am -s mbox
> > $ git range-diff @{-1}...
> > $ git checkout -B @{-1}
> >
> >
On Thu, Aug 30, 2018 at 09:53:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > In the SYNOPSIS section we still see "[-l]" listed; that also must
> > be replaced with "--create-reflog", or just dropped, as that is the
> > default.
>
> Oh yes, it seems all of the doc indeed wasn't updated!
Sorry,
The tmp-doc-diff directory isn't strictly a build product of
the Makefile, since it's only present if you manually run
the doc-diff script. But anybody running "make clean" would
probably want it to go away.
Suggested-by: Eric Sunshine
Signed-off-by: Jeff King
---
> Another fixup for
On Thu, Aug 30 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>>> +-l::
>>> --list::
>>> List branches. With optional `...`, e.g. `git
>>> branch --list 'maint-*'`, list only the branches that match
>>
>> I think it's better to have something like this on top:
>>
>>
On Thu, Aug 30, 2018 at 05:04:32AM -0400, Eric Sunshine wrote:
> On Thu, Aug 30, 2018 at 3:54 AM Jeff King wrote:
> > Subject: [PATCH] doc-diff: force worktree add
> >
> > We avoid re-creating our temporary worktree if it's already
> > there. But we may run into a situation where the worktree
>
On Thu, Aug 30, 2018 at 02:18:19PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > It doesn't need to be. As far as I know, the main reasons (from the
> > perspective of a project) to do it through Outreachy are:
> >
> > - being part of a larger program generates attention and gets the
> >interest
On 2018-08-30 20:13, Eric Sunshine wrote:
> On Thu, Aug 30, 2018 at 7:26 AM Rasmus Villemoes
> wrote:
>> I can set GIT_COMMITTER_EMAIL in the environment, but that is
>> rather inconvenient, since that means I have to remember to do that in
>> the shell I'm using for that particular project, and
On Thu, Aug 30, 2018 at 12:20 PM Jeff King wrote:
>
> On Thu, Aug 30, 2018 at 12:16:22PM -0700, Stefan Beller wrote:
>
> > On Wed, Aug 29, 2018 at 7:54 PM Jeff King wrote:
> > >
> > > On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
> > >
> > > > > Could you cut down to a real
On Thu, Aug 30, 2018 at 01:46:00PM +0200, Johannes Schindelin wrote:
> On Wed, 29 Aug 2018, Jeff King wrote:
>
> > - it naturally limits the candidate pool to under-represented groups
> > (which is the whole point of the program, but if you don't
> > actually care about that, then it's
On Thu, Aug 30, 2018 at 12:16:22PM -0700, Stefan Beller wrote:
> On Wed, Aug 29, 2018 at 7:54 PM Jeff King wrote:
> >
> > On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
> >
> > > > Could you cut down to a real minimal reproduction, i.e. just these 20
> > > > lines or so?
> > >
On Wed, Aug 29, 2018 at 7:54 PM Jeff King wrote:
>
> On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
>
> > > Could you cut down to a real minimal reproduction, i.e. just these 20
> > > lines or so?
> >
> > I'm working on getting down to a minimal reproduction, a few lines at
> >
On Thu, Aug 30, 2018 at 11:50:56AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I can re-roll, or even prepare a patch on top (it's sufficiently subtle
> > that it may merit calling out explicitly in a commit).
>
> Yeah, I tend to agree with your reasoning to do it on top as a
>
On August 30, 2018 2:57 PM, Torsten Bögershausen wrote:
> On Thu, Aug 30, 2018 at 09:57:52AM -0500, Robert Dailey wrote:
> > On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder
> wrote:
> > >
> > > Hi,
> > >
> > > Robert Dailey wrote:
> > >
> > > > Is there an 'auto' setting for the 'core.autocrlf'
On Thu, Aug 30, 2018 at 09:57:52AM -0500, Robert Dailey wrote:
> On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder wrote:
> >
> > Hi,
> >
> > Robert Dailey wrote:
> >
> > > Is there an 'auto' setting for the 'core.autocrlf' config? Reason I
> > > ask is, I want that setting to be 'input' on linux
Jeff King writes:
> I can re-roll, or even prepare a patch on top (it's sufficiently subtle
> that it may merit calling out explicitly in a commit).
Yeah, I tend to agree with your reasoning to do it on top as a
separate patch.
Ævar Arnfjörð Bjarmason writes:
>> +-l::
>> --list::
>> List branches. With optional `...`, e.g. `git
>> branch --list 'maint-*'`, list only the branches that match
>
> I think it's better to have something like this on top:
>
> diff --git a/Documentation/git-branch.txt
On Thu, Aug 30, 2018 at 02:42:01PM -0400, Jeff King wrote:
> > Would "echo base >base" give us 5-byte long base even on Windows?
> > Or the test does not care if it is either "base\n" or "base\r\n"?
> >
> > Just double-checking.
>
> Good question. On the first one, I don't know. On the second
On Thu, Aug 30, 2018 at 10:38:21AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +test_expect_success \
> > +'apply delta with too many copied bytes' \
> > +'printf "\5\1\221\0\2" > too_big_copy &&
> > + echo base >base &&
> > + test_must_fail test-tool delta -p base
On Thu, Aug 30, 2018 at 7:26 AM Rasmus Villemoes
wrote:
> I can set GIT_COMMITTER_EMAIL in the environment, but that is
> rather inconvenient, since that means I have to remember to do that in
> the shell I'm using for that particular project, and I can't use that
> shell for other projects. So
Jeff King writes:
> +test_expect_success \
> +'apply delta with too many copied bytes' \
> +'printf "\5\1\221\0\2" > too_big_copy &&
> + echo base >base &&
> + test_must_fail test-tool delta -p base too_big_copy /dev/null'
Would "echo base >base" give us 5-byte long base even on
Hi Duy,
On Tue, Aug 21, 2018 at 7:52 AM Duy Nguyen wrote:
>
> On Mon, Aug 20, 2018 at 8:16 PM Elijah Newren wrote:
> > Playing with sparse-checkout, it feels to me like a half-baked
> > feature. It seems like it required too much manual work, and it was
> > sometimes hard to tell if I was
On Thu, Aug 30, 2018 at 4:33 AM Johannes Schindelin
wrote:
>
> Hi Piers,
>
> On Thu, 30 Aug 2018, Piers Titus van der Torren wrote:
>
> > I've created a diff algorithm that focuses on creating readable diffs,
> > see https://github.com/pierstitus/klondiff
>
> Looks intriguing.
Yes it does.
The
On Thu, Aug 30, 2018 at 5:23 PM Junio C Hamano wrote:
>
> Ævar Arnfjörð Bjarmason writes:
>
> > I.e. the non-refs/{tags,heads}/* update logic treats all updates to
> > tags/commits as branch updates. We just look at the tag v2.18.0, see you
> > want to replace it with the commit v2.19.0-rc0^{}
On Tue, Aug 28, 2018 at 9:58 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > - Add a flag to turn off directory rename detection, and set the
> > flag for every call from am.c in order to avoid problems like this.
>
> I'd say this is the only practical solution, before you deprecate
>
On Thu, Aug 30, 2018 at 9:01 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> Is this a single-shot environment assignment? That would have been
> >> caught with the test linter.
> >
> > Ugh, yes. Sorry.
> >
> > I was trying to allow backporting to 2.18, so tried to build my series
>
On Thu, Aug 30, 2018 at 8:44 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> Recent addition of "directory rename" heuristics to the
> >> merge-recursive backend makes the command susceptible to false
> >> positives and false negatives, but the risk is even more grave when
> >>
Elijah Newren writes:
>> Is this a single-shot environment assignment? That would have been
>> caught with the test linter.
>
> Ugh, yes. Sorry.
>
> I was trying to allow backporting to 2.18, so tried to build my series
> on that...but moved forward slightly to en/rebase-consistency in order
>
Elijah Newren writes:
>> Recent addition of "directory rename" heuristics to the
>> merge-recursive backend makes the command susceptible to false
>> positives and false negatives, but the risk is even more grave when
>> used in the context of "git am -3", which does not know about any
>>
Rasmus Villemoes writes:
> ... I can set GIT_COMMITTER_EMAIL in the environment, but that is
> rather inconvenient, since that means I have to remember to do that in
> the shell I'm using for that particular project, and I can't use that
> shell for other projects.
We only have user.email and
"Derrick Stolee via GitGitGadget" writes:
> As I was testing the release candidate, I stumbled across a regression in
> 'git merge-base' as a result of the switch to generation numbers. The commit
> message in [PATCH 1/1] describes the topology involved,...
I do not recall having seen this kind
On Thu, 30 Aug 2018, Jeff King wrote:
> On Wed, Aug 29, 2018 at 10:58:55PM +0200, Jann Horn wrote:
>
> > If `cmd` is in the range [0x01,0x7f] and `cmd > top-data`, the
> > `memcpy(out, data, cmd)` can copy out-of-bounds data from after `delta_buf`
> > into `dst_buf`.
> >
> > This is not an
Ævar Arnfjörð Bjarmason writes:
> I.e. the non-refs/{tags,heads}/* update logic treats all updates to
> tags/commits as branch updates. We just look at the tag v2.18.0, see you
> want to replace it with the commit v2.19.0-rc0^{} and see "oh, that's a
> fast-forward".
In my old message you are
On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder wrote:
>
> Hi,
>
> Robert Dailey wrote:
>
> > Is there an 'auto' setting for the 'core.autocrlf' config? Reason I
> > ask is, I want that setting to be 'input' on linux but 'true' on
> > Windows.
>
> Others are exploring your question about the
On Mon, Aug 27, 2018 at 12:32 PM Andrei Rybak wrote:
>
> On 2018-08-27 17:52, Duy Nguyen wrote:
> > On Mon, Aug 27, 2018 at 5:37 PM Torsten Bögershausen wrote:
> >>> In those cases, when it falls back to
> >>> configuration for line ending management, I want it to be
> >>> automatically
On Tue, Jul 31 2018, Junio C Hamano wrote:
I'm finally getting to re-rolling this. Just some inline comments.
> Ævar Arnfjörð Bjarmason writes:
>
>> The is often the name of the branch you would want to push, but
>> -it can be any arbitrary "SHA-1 expression", such as `master~4` or
>>
Phillip Wood writes:
> When $newhunk is created it is marked as dirty to prevent
> coalesce_overlapping_hunks() from coalescing it. This patch does not
> change that. What is happening is that by calling
> coalesce_overlapping_hunks() the hunks that are not currently selected
> are filtered out
On Thu, Aug 30 2018, Wesley Schwengle wrote:
> Hello all,
>
> I would like to ask if it is worth my time looking into the following
> solution to a problem we have at work.
>
> Problem:
> We want to have some git-hooks and we want to provide them to the
> user. In a most recent example we have
Bonjour
Vous aviez besoin de prêts d'argent entre particuliers pour faire face
aux difficultés financières pour enfin sortir de l'impasse que
provoquent les banques, par le rejet de vos dossiers de demande de
crédits ? Je suis Pierre ARNOUX, citoyen français, et gestionnaire de
Portefeuille de la
Ævar Arnfjörð Bjarmason writes:
> I believe the "official" way, such as it is, is you just put
> #leftoverbits in your E-Mail, then search the list archives,
> e.g. https://public-inbox.org/git/?q=%23leftoverbits
I think that technique has been around long enough to be called a
recognised way,
Hi Ævar,
On Thu, 30 Aug 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Aug 30 2018, Johannes Schindelin wrote:
>
> > On Wed, 29 Aug 2018, Junio C Hamano wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> > The `stash` command only incidentally requires that the author is set, as
> >> > it
Hi Junio,
On Wed, 29 Aug 2018, Junio C Hamano wrote:
> * es/format-patch-interdiff (2018-07-23) 6 commits
> - format-patch: allow --interdiff to apply to a lone-patch
> - log-tree: show_log: make commentary block delimiting reusable
> - interdiff: teach show_interdiff() to indent interdiff
>
Dear Jochen/Junio
On 28/08/18 19:07, Junio C Hamano wrote:
Jochen Sprickerhof writes:
When a hunk was split before being edited manually, it does not apply
anymore cleanly. Apply coalesce_overlapping_hunks() first to make it
work. Enable test for it as well.
Signed-off-by: Jochen
On Thu, Aug 30, 2018 at 9:05 AM Jeff King wrote:
>
> On Wed, Aug 29, 2018 at 10:58:55PM +0200, Jann Horn wrote:
>
> > If `cmd` is in the range [0x01,0x7f] and `cmd > top-data`, the
> > `memcpy(out, data, cmd)` can copy out-of-bounds data from after `delta_buf`
> > into `dst_buf`.
> >
> > This is
Hello all,
I would like to ask if it is worth my time looking into the following
solution to a problem we have at work.
Problem:
We want to have some git-hooks and we want to provide them to the
user. In a most recent example we have a post-checkout hook that deals
with some Docker things.
From: Derrick Stolee
In 3afc679b "commit: use generations in paint_down_to_common()",
the queue in paint_down_to_common() was changed to use a priority
order based on generation number before commit date. This served
two purposes:
1. When generation numbers are present, the walk guarantees
As I was testing the release candidate, I stumbled across a regression in
'git merge-base' as a result of the switch to generation numbers. The commit
message in [PATCH 1/1] describes the topology involved, but you can test it
yourself by comparing 'git merge-base v4.8 v4.9' in the Linux kernel.
On Thu, Aug 30 2018, Johannes Schindelin wrote:
> Hi Junio,
>
> On Wed, 29 Aug 2018, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > The `stash` command only incidentally requires that the author is set, as
>> > it calls `git commit` internally (which records the author). As
On Thu, Aug 30 2018, Jeff King wrote:
> On Wed, Aug 29, 2018 at 03:12:37PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > 2. To get our landing page and list of projects in order (and also
>> > micro-projects for applicants). This can probably build on the
>> > previous round at:
>> >
1 - 100 of 131 matches
Mail list logo
