On Fri, Oct 26, 2018 at 11:07:33PM +, Ævar Arnfjörð Bjarmason wrote:
> After sending out v2 I noticed I didn't update the examples in a
> couple of the commit messages, and figured I'd finish this up by
> adding a patch to document how this works in the "git-push"
> manpage. This behavior has
On Mon, Oct 29, 2018 at 02:14:02PM +0900, Junio C Hamano wrote:
> Any failure in the &&-chain (or the last grep) would not terminate
> the for loop, so for the purpose of determining the success of this
> test_expect_success, the last "blob" iteration is the only thing
> that matters.
>
> Which i
This function was used only for parsing the hunk headers generated by
xdiff. Now that we can use hunk callbacks to get that information
directly, it has outlived its usefulness.
Note to anyone who wants to resurrect it: the "len" parameter was
totally unused, meaning that the function could read p
When we count the lines in a diff, we don't actually care about the
contents of each line. By using a hunk callback, we tell xdiff that it
does not need to even bother generating a hunk header line, saving a
small amount of work.
Arguably we could even ignore the hunk headers completely, since we'
The "diff --check" code needs to know the line number on which each hunk
starts in order to generate its output. We get that now by parsing the
hunk header line generated by xdiff, but it's much simpler to just pass
it directly using a hunk callback.
Signed-off-by: Jeff King
---
diff.c | 20
A combined diff has to line up the hunks for all of the individual
pairwise diffs, and thus needs to know their line numbers and sizes. We
get that now by parsing the hunk header line that xdiff generates.
However, now that xdiff supports a hunk callback, we can just use the
values directly.
Signe
Our word-diff does not look at the -/+ lines generated by xdiff at all
(because they are not real lines to show the user, but just the
tokenized words split into lines). Instead we use the line numbers from
the hunk headers to index our own data structure.
As a result, our xdi_diff_outf() callback
We do not include hunk header lines when computing patch-ids, since
the line numbers would create false negatives. Rather than detect and
skip them in our line callback, we can simply tell xdiff to avoid
generating them.
This is similar to the previous commit, but split out because it
actually req
Some callers of xdi_diff_outf() do not look at the generated hunk header
lines at all. By plugging in a no-op hunk callback, this tells xdiff not
to even bother formatting them.
This patch introduces a stock no-op callback and uses it with a few
callers whose line callbacks explicitly ignore hunk
The previous commit taught xdiff to optionally provide the hunk header
data to a specialized callback. But most users of xdiff actually use our
more convenient xdi_diff_outf() helper, which ensures that our callbacks
are always fed whole lines.
Let's plumb the special hunk-callback through this in
The xdiff library always emits hunk header lines to our callbacks as
formatted strings like "@@ -a,b +c,d @@\n". This is convenient if we're
going to output a diff, but less so if we actually need to compute using
those numbers, which requires re-parsing the line.
In preparation for moving away fr
As part of my -Wunused-parameter hunt, I noticed that parse_hunk_header()
can read out-of-bounds in the array it is given. But it turns out not to
be a big problem because we only ever use it to parse lines that xdiff
has just generated.
This is fixable, and I'll show my patch to do so at the end
On Fri, Nov 02, 2018 at 03:05:03PM +0900, Junio C Hamano wrote:
> Remnant of the old name of the function still remains in comments.
> Update them all.
Yay. What's here looks obviously correct.
> Signed-off-by: Junio C Hamano
> ---
> apply.c | 2 +-
> builtin/gc.c | 2 +-
> fast-import.
Farhan Khan writes:
> ...Where is this in the git code? That might
> serve as a good guide.
There are two major codepaths. One is used at runtime, giving us
random access into the packfile with the help with .idx file. The
other is used when receiving a new packstream to create an .idx
file.
Remnant of the old name of the function still remains in comments.
Update them all.
Signed-off-by: Junio C Hamano
---
apply.c | 2 +-
builtin/gc.c | 2 +-
fast-import.c | 4 ++--
notes.c | 2 +-
object.h | 2 +-
sha1-file.c | 2 +-
6 files changed, 7 insertions(+), 7 deletion
The approxidate parser has a table of special keywords like
"yesterday", "noon", "pm", etc. Some of these, like "pm", do
the right thing if we've recently seen a number: "3pm" is
what you'd think.
However, most of them do not look at or modify the
pending-number flag at all, which means a number m
When a traversal sees the --indexed-objects option, it adds
all blobs and valid cache-trees from the index to the
traversal using add_index_objects_to_pending(). But that
function totally ignores its flags parameter!
That means that doing:
git rev-list --objects --indexed-objects
and
git re
The pathspec code always takes names to be matched as a
name/namelen pair, but match_attrs() never looks at namelen,
and just treats "name" like a NUL-terminated string, passing
it to git_check_attr().
This usually works anyway. Every caller passes a
NUL-terminated string, and in all but one the p
Hi all,
I am trying to understand the pack file format and have been reading
the documentation, specifically https://git-scm.com/docs/pack-format
(which is in git's own git repository as
"Documentation/technical/pack-format.txt"). I see that the file starts
with the "PACK" signature, followed by t
Here are three minor bug-fixes that can be applied independently. The
common thread is that I found them by looking at the results of
compiling with -Wunused-parameter. In each of these cases, the parameter
_should_ be used, and not doing so was a bug.
[1/3]: rev-list: handle flags for --indexed
Junio C Hamano writes:
> As we currently have no idea when builtin/stash.c becomes ready for
> 'next', how about doing something like this instead, in order to
> help end-users without waiting in the meantime? The fix can be
> picked up and ported when the C rewrite is updated, of course.
I thi
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The eighth batch is all about "reb
The "git stash" command insists on having a usable user identity to
the same degree as the "git commit-tree" and "git commit" commands
do, because it uses the same codepath that creates commit objects
as these commands.
It is not strictly necesary to do so. Check if we will barf before
creating c
Junio C Hamano writes:
> Rather than adding this fallback trap, can't we do it more like
> this?
>
> - At the beginning of "git stash", after parsing the command
> line, we know what subcommand of "git stash" we are going to
> run.
>
> - If it is a subcommand that could need t
Ævar Arnfjörð Bjarmason writes:
> Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON
> test parameter to only be a GIT_TEST_GETTEXT_POISON=
> runtime parameter, to be consistent with other parameters documented
> in "Running tests with special setups" in t/README.
> ...
> #ifnd
Sirio Balmelli writes:
> It appears that git ignores the GIT_CONFIG environment variable,
> while git-config *does* consider it.
Yup, that is exactly how it is designed and documented. These
dasys, with "git config" taking "--file" to work on any arbitrary
filename, you do not necessarily need
Slavica Djukic writes:
> Usually, when creating a commit, ident is needed to record the author
> and commiter.
> But, when there is commit not intended to published, e.g. when stashing
> changes, valid ident is not necessary.
> To allow creating commits in such scenario, let's introduce helper
>
I’m attempting to perform fixups via git-rebase of UTF-16 LE files
(the project I’m working on requires that exact encoding on certain
files). When the rebase is complete, Git changes that file’s encoding
to UTF-16 BE. I have been using the newer working-tree-encoding
attribute in .gitattributes. I
SZEDER Gábor writes:
> Ever since we started using Travis CI, we specified the list of
> packages to install in '.travis.yml' via the APT addon. While running
> our builds on Travis CI's container-based infrastructure we didn't
> have another choice, because that environment didn't support 'sudo
Stefan Beller writes:
>> What was posted would have been perfectly fine as a "how about doing
>> it this way" weatherbaloon patch, but as a part of real series, it
>> needs to explain to the developers what the distinctions between two
>> classes are, and who is to use the cocci patch at what poi
On Thu, Nov 01, 2018 at 09:09:34PM -0400, Aaron Lindsay wrote:
> Fix a small bug introduced by "7a36987ff (send-email: add an auto option
> for transfer encoding, 2018-07-14)
>
> I saw the following message when setting --transfer-encoding for a file
> with the same encoding:
> $ git send-emai
Derrick Stolee writes:
> We could do this, but it does come with a performance hit when the following
> are all true:
>
> 1. 'to' is not reachable from any 'from' commits.
>
> 2. The 'to' and 'from' commits are close in commit-date.
>
> 3. Generation numbers are not available, or the topology is
It appears that git ignores the GIT_CONFIG environment variable, while
git-config *does* consider it.
I have written a short script that shows this in detail and reproduces, it is
included below and also posted on github at
https://github.com/siriobalmelli/toolbench/blob/master/git/git-env-chec
On Wed, Oct 31, 2018 at 1:42 PM Stefan Beller wrote:
>
> On Tue, Oct 30, 2018 at 7:06 PM james harvey wrote:
> > I think "--color-moved" should have precedence over "--word-diff".
>
> I agree for precedence as in "work well together". Now we'd need
> to figure out what that means. In its current
Fix a small bug introduced by "7a36987ff (send-email: add an auto option
for transfer encoding, 2018-07-14)
I saw the following message when setting --transfer-encoding for a file
with the same encoding:
$ git send-email --transfer-encoding=8bit example.patch
Use of uninitialized value $xf
Derrick Stolee writes:
> On 11/1/2018 5:59 AM, Junio C Hamano wrote:
>> --
>> [Graduated to "master"]
>
> I see that several topics graduated, but it appears the master branch
> was not updated at https://github.com/gister/git. Was this
> intentiona
Derrick Stolee writes:
>> Review discussions seem to have petered out. Would we merge this to
>> 'next' and start cooking, perhaps for the remainder of this cycle?
>
> Thanks, but I've just sent a v5 responding to Jakub's feedback on v4. [1]
>
> I'd be happy to let it sit in next until you feel
Duy Nguyen writes:
>> > I have no comment about this. In an ideal world, sendemail.perl could
>> > be taught to support --git-completion-helper but I don't think my
>> > little remaining Perl knowledge (or time) is enough to do it. Perhaps
>> > this will do. I don't know.
>>
>> So "all", "attach"
Johannes Sixt writes:
> Am 01.11.18 um 07:12 schrieb Junio C Hamano:
>> "Johannes Schindelin via GitGitGadget"
>> writes:
>>
>>> The `--preserve-merges` mode of the `rebase` command is slated to be
>>> deprecated soon, ...
>>
>> Is everybody on board on this statement? I vaguely recall that som
Le 30/10/2018 à 17:47, Phillip Wood a écrit :
> On 27/10/2018 22:29, Alban Gruin wrote:
>> This refactors sequencer_add_exec_commands() to work on a todo_list to
>> avoid redundant reads and writes to the disk.
>>
>> An obvious way to do this would be to insert the `exec' command between
>> the oth
Hi Phillip,
Le 30/10/2018 à 17:28, Phillip Wood a écrit :
> Hi Alban
>
> I like the direction this is going, it is an improvement on re-scanning
> the list at the end of each function.
>
> On 27/10/2018 22:29, Alban Gruin wrote:
>> This introduce a new function to recreate the text of a todo lis
Derrick Stolee writes:
> Here is a re-formatted version of the tables I introduced earlier.
> The tables were too wide for public-inbox to render correctly (when
> paired with my email client). Hopefully this bulleted-list format
> works better. Thanks, Stefan, for pointing out the rendering
> pr
On Fri, Oct 26, 2018 at 09:52:24AM +0900, Junio C Hamano wrote:
> Eric Sunshine writes:
>
> >> + test_when_finished "git tag -d branch-and-tag-name" &&
> >> + git tag branch-and-tag-name &&
> >
> > If git-tag crashes before actually creating the new tag, then "git tag
> > -d", passed
On Wed, Oct 31, 2018 at 07:28:09AM +0100, Christian Couder wrote:
> > For (2), I would like to see us improve the remote helper
> > infrastructure instead of introducing a new ODB helper. Remote
> > helpers are already permitted to fetch some objects without listing
> > refs --- perhaps we will w
Stefan Beller writes:
>> Based on the performance results alone, we should remove minimum
>> generation numbers, (epoch, date) pairs, and FELINE index from
>> consideration. There are enough examples of these indexes performing
>> poorly.
>>
>> In contrast, maximum generation numbers and correcte
On Tue, Oct 30, 2018 at 11:41 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > I also picked up the patch for pending semantic patches, as the
> > first patch, can I have your sign off, please?
>
> I find this step quite lacking.
>
> What was posted would have been perfectly fine as a "ho
On Thu, Nov 01 2018, Duy Nguyen wrote:
> On Thu, Nov 1, 2018 at 3:04 PM Junio C Hamano wrote:
>>
>> Ævar Arnfjörð Bjarmason writes:
>>
>> > Could you please pick up
>> > https://public-inbox.org/git/20181024114725.3927-1-ava...@gmail.com/ ?
>> > It seems to have fallen between the cracks and a
Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON
test parameter to only be a GIT_TEST_GETTEXT_POISON=
runtime parameter, to be consistent with other parameters documented
in "Running tests with special setups" in t/README.
When I added GETTEXT_POISON in bb946bba76 ("i18n: add GE
On Wed, Oct 31, 2018 at 6:38 AM Derrick Stolee wrote:
>
> On 10/16/2018 7:35 PM, Stefan Beller wrote:
> > @@ -482,14 +483,46 @@ void prepare_submodule_repo_env(struct argv_array
> > *out)
> >DEFAULT_GIT_DIR_ENVIRONMENT);
> > }
> >
> > -/* Helper function to display the s
On 11/1/2018 2:57 PM, Elijah Newren wrote:
On Thu, Nov 1, 2018 at 5:32 AM Derrick Stolee wrote:
No rush. I'd just like to understand how removing the commit-graph file
can make the new algorithm faster. Putting a similar count in the old
algorithm would involve giving a count for every call to
On Thu, Nov 1, 2018 at 5:32 AM Derrick Stolee wrote:
> On 11/1/2018 2:52 AM, Elijah Newren wrote:
> > On Wed, Oct 31, 2018 at 5:05 AM Derrick Stolee wrote:
> >> On 10/31/2018 2:04 AM, Elijah Newren wrote:
> >>>
> >>> On the original repo where the topic was brought up, with commit-graph
> >>> NOT
On Thu, Nov 01, 2018 at 12:01:28AM +0100, Anders Waldenborg wrote:
> Jeff King writes:
>
> > On the other hand, if the rule were not "this affects the next
> > placeholder" but had a true ending mark, then we could make a real
> > parse-tree out of it, and format chunks of placeholders. E.g.:
> >
On Thu, Nov 01, 2018 at 12:48:04AM +, brian m. carlson wrote:
> > So a few questions:
> >
> > - is this a bug or not? I.e., do we still need to care about proxies
> > that can't handle Expect? The original commit was from 2011. Maybe
> > things are better now. Or maybe that's blind
Am 01.11.18 um 07:12 schrieb Junio C Hamano:
"Johannes Schindelin via GitGitGadget"
writes:
The `--preserve-merges` mode of the `rebase` command is slated to be
deprecated soon, ...
Is everybody on board on this statement? I vaguely recall that some
people wanted to have something different
On Thu, Oct 11, 2018 at 9:38 PM Daniels Umanovskis
wrote:
>
> Also remove git-cherry from Bash completion because plumbing
> commands do not belong there.
Er.. why?
>
> Signed-off-by: Daniels Umanovskis
> ---
>
> Up to discussion whether cherry should be considered plumbing.
> I lean towards co
Hi Junio
On 01/11/2018 03:01, Junio C Hamano wrote:
Phillip Wood writes:
From: Phillip Wood
Sorry for the confusion with v3, here are the updated patches.
Thanks to Junio for the feedback on v2. I've updated patch 4 based on
those comments, the rest are unchanged.
The mistake of overwrit
Today's test report doesn't contain any information for the 'master'
branch because the ref was not updated before this run (see 'master' and
'master@{1}' are the same below). If 'master' updates today, then I will
rerun the build and send the report for new lines in 'next' and 'master'.
Thanks,
On 11/1/2018 11:48 AM, SZEDER Gábor wrote:
On Thu, Nov 01, 2018 at 01:46:22PM +, Derrick Stolee wrote:
1. EXPLORE: using the explore_queue priority queue (ordered by
maximizing the generation number)
2. INDEGREE: using the indegree_queue priority queue (ordered
by maximizing the gene
On 11/1/2018 5:59 AM, Junio C Hamano wrote:
--
[Graduated to "master"]
I see that several topics graduated, but it appears the master branch
was not updated at https://github.com/gister/git. Was this intentional?
I noticed because the test-cove
On Thu, Nov 01, 2018 at 01:46:22PM +, Derrick Stolee wrote:
> 1. EXPLORE: using the explore_queue priority queue (ordered by
>maximizing the generation number)
> 2. INDEGREE: using the indegree_queue priority queue (ordered
>by maximizing the generation number)
Nit: I've been ponderin
On Thu, Nov 1, 2018 at 2:42 AM Junio C Hamano wrote:
> >> @@ -2080,16 +2071,19 @@ _git_send_email ()
> >> return
> >> ;;
> >> --*)
> >> - __gitcomp "--annotate --bcc --cc --cc-cmd --chain-reply-to
> >> - --compose --confir
On Thu, Nov 1, 2018 at 3:04 PM Junio C Hamano wrote:
>
> Ævar Arnfjörð Bjarmason writes:
>
> > Could you please pick up
> > https://public-inbox.org/git/20181024114725.3927-1-ava...@gmail.com/ ?
> > It seems to have fallen between the cracks and addressed the feedback on
> > v1, and looks good to
On November 1, 2018 10:13 AM, Christian Couder wrote:
> Sent: > To: nicolas.mail...@laposte.net
> Cc: git
> Subject: Re: [RFE] Please add name and email to git credentials
>
> On Thu, Nov 1, 2018 at 2:31 PM Nicolas Mailhot
> wrote:
> >
> > Le jeudi 01 novembre 2018 à 12:22 +0100, Ævar Arnfjörð B
On Thu, Nov 1, 2018 at 2:31 PM Slavica Djukic
wrote:
>
> Add test to assert that stash fails if user.name and user.email
Nit: I am not sure that "assert" is the right word here.
test_expect_failure() is more for documenting an existing bug than for
really asserting a behavior (that users could re
Le jeudi 01 novembre 2018 à 15:13 +0100, Christian Couder a écrit :
>
> How can Git know when you commit where you will want to push the
> commit afterwards?
You have an url in the repo config. of course you can change it between
the commit and the push, but that's not the general case.
Nowadays
Le jeudi 01 novembre 2018 à 14:09 +0100, Ævar Arnfjörð Bjarmason a
é
> You're the one trying to ostensibly file some sort of bug report or
> feature request, it's up to you to explain the problem in detail.
>
> > I’m just asking that when a project releases “x.y.z”
> >
> > 1. there was a standar
On Thu, Nov 01, 2018 at 02:46:41PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > However, if you push that patch with 'sh-i18n--helper' as-is, then I
> > do object now: parsing a boolean in shell is not at all that difficult
> > to justify this new command.
>
> So instead of calling a helper (which is
On Thu, Nov 1, 2018 at 2:31 PM Nicolas Mailhot
wrote:
>
> Le jeudi 01 novembre 2018 à 12:22 +0100, Ævar Arnfjörð Bjarmason a
> écrit :
> >
> > Where would we get an E-Mail to lookup to pass to the helper? Are you
> > just asking that the helper git the result of $(git config user.name
> > &&
> > g
On 11/1/2018 1:21 AM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
This patch series performs a decently-sized refactoring of the revision-walk
machinery. Well, "refactoring" is probably the wrong word, as I don't
actually remove the old code. Instead, when we see certain op
On Thu, Nov 01 2018, SZEDER Gábor wrote:
> On Thu, Nov 01, 2018 at 12:02:01PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> Could you please pick up
>> https://public-inbox.org/git/20181024114725.3927-1-ava...@gmail.com/ ?
>> It seems to have fallen between the cracks and addressed the feedback on
>>
The current --topo-order algorithm requires walking all
reachable commits up front, topo-sorting them, all before
outputting the first value. This patch introduces a new
algorithm which uses stored generation numbers to
incrementally walk in topo-order, outputting commits as
we go. This can dramati
The 'test_three_modes' method assumes we are using the 'test-tool
reach' command for our test. However, we may want to use the data
shape of our commit graph and the three modes (no commit-graph,
full commit-graph, partial commit-graph) for other git commands.
Split test_three_modes to be a simple
The rev-list command is critical to Git's functionality. Ensure it
works in the three commit-graph environments constructed in
t6600-test-reach.sh. Here are a few important types of rev-list
operations:
* Basic: git rev-list --topo-order HEAD
* Range: git rev-list --topo-order compare..HEAD
* Ance
There are a few things that need to move around a little before
making a big refactoring in the topo-order logic:
1. We need access to record_author_date() and
compare_commits_by_author_date() in revision.c. These are used
currently by sort_in_topological_order() in commit.c.
2. Moving thes
When running 'git rev-list --topo-order' and its kin, the topo_order
setting in struct rev_info implies the limited setting. This means
that the following things happen during prepare_revision_walk():
* revs->limited implies we run limit_list() to walk the entire
reachable set. There are some sh
As we are working to rewrite some of the revision-walk machinery,
there could easily be some interesting interactions between the
options that force topological constraints (--topo-order,
--date-order, and --author-date-order) along with specifying a
path.
Add extra tests to t6012-rev-list-simplif
This patch series performs a decently-sized refactoring of the
revision-walk machinery. Well, "refactoring" is probably the wrong word,
as I don't actually remove the old code. Instead, when we see certain
options in the 'rev_info' struct, we redirect the commit-walk logic to
a new set of methods t
When consuming a priority queue, it can be convenient to inspect
the next object that will be dequeued without actually dequeueing
it. Our existing library did not have such a 'peek' operation, so
add it as prio_queue_peek().
Add a reference-level comparison in t/helper/test-prio-queue.c
so this m
On 11/1/2018 8:27 AM, Jakub Narebski wrote:
[I have noticed that in some places I wrote A..B instead of B..A. Sorry
about that]
Derrick Stolee writes:
Please also let me know about any additional tests that I could
run. Now that I've got a lot of test scripts built up, I can re-run
the tes
Ævar Arnfjörð Bjarmason writes:
> Could you please pick up
> https://public-inbox.org/git/20181024114725.3927-1-ava...@gmail.com/ ?
> It seems to have fallen between the cracks and addressed the feedback on
> v1, and looks good to me (and nobody's objected so far...).
If this is the runtime-gett
On Thu, Nov 01 2018, Nicolas Mailhot wrote:
> Le jeudi 01 novembre 2018 à 12:22 +0100, Ævar Arnfjörð Bjarmason a
> écrit :
>>
>> Where would we get an E-Mail to lookup to pass to the helper? Are you
>> just asking that the helper git the result of $(git config user.name
>> &&
>> git config user.
On Thu, Nov 01, 2018 at 12:02:01PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Could you please pick up
> https://public-inbox.org/git/20181024114725.3927-1-ava...@gmail.com/ ?
> It seems to have fallen between the cracks and addressed the feedback on
> v1, and looks good to me (and nobody's objected s
On Thu, Nov 01 2018, Nicolas Mailhot wrote:
> Le jeudi 01 novembre 2018 à 12:15 +0100, Ævar Arnfjörð Bjarmason a
> écrit :
>>
>> For both this and your other report, it would be helpful if you
>> describe
>> in concrete terms (with examples of git commands, or UI etc.) what git
>> commands do no
Le jeudi 01 novembre 2018 à 12:22 +0100, Ævar Arnfjörð Bjarmason a
écrit :
>
> Where would we get an E-Mail to lookup to pass to the helper? Are you
> just asking that the helper git the result of $(git config user.name
> &&
> git config user.email)? If so why can't it just look this up itself?
On 11/1/2018 2:52 AM, Elijah Newren wrote:
On Wed, Oct 31, 2018 at 5:05 AM Derrick Stolee wrote:
On 10/31/2018 2:04 AM, Elijah Newren wrote:
On the original repo where the topic was brought up, with commit-graph
NOT turned on and using origin/master, I see:
$ time git push --dry-run --follow
[I have noticed that in some places I wrote A..B instead of B..A. Sorry
about that]
Derrick Stolee writes:
> We've discussed in several places how to improve upon generation
> numbers. This RFC is a report based on my investigation into a
> few new options, and how they compare for Git's purpo
Le jeudi 01 novembre 2018 à 12:15 +0100, Ævar Arnfjörð Bjarmason a
écrit :
>
> For both this and your other report, it would be helpful if you
> describe
> in concrete terms (with examples of git commands, or UI etc.) what git
> commands do now, what's wrong with it, and some sketch of what you
>
Call set_fallback_ident() in cmd_stash() and update test
from the first commit to expect success.
Executing stash without user.name and user.email configured
can be useful when bots or similar users use stash, without anyone
specifing valid ident. Use case would be automated testing.
There are als
Usually, when creating a commit, ident is needed to record the author
and commiter.
But, when there is commit not intended to published, e.g. when stashing
changes, valid ident is not necessary.
To allow creating commits in such scenario, let's introduce helper
function "set_fallback_ident(), whic
Add test to assert that stash fails if user.name and user.email
are not configured.
In the final commit, test will be updated to expect success.
Signed-off-by: Slavica Djukic
---
t/t3903-stash.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/t/t3903-stash.sh b/t/t3903-stas
Enhancement request that ask for 'git stash' to work even if
'user.name' and 'user.email' are not configured.
Due to an implementation detail, git-stash undesirably requires
'user.name' and 'user.email' to be set, but shouldn't.
Slavica Djukic(3):
[Outreachy] t3903-stash: test without configur
Ever since we started using Travis CI, we specified the list of
packages to install in '.travis.yml' via the APT addon. While running
our builds on Travis CI's container-based infrastructure we didn't
have another choice, because that environment didn't support 'sudo',
and thus we didn't have perm
Le jeudi 01 novembre 2018 à 10:59 +0100, Nicolas Mailhot a écrit :
> Hi,
>
> A dev persona is not just a username, please add email (and probably
> also name) support to git credentials so the correct set for a repo
> url
> is automatically picked up by git
So, just in case it was not clear enoug
On Thu, Nov 01 2018, Nicolas Mailhot wrote:
> A dev persona is not just a username, please add email (and probably
> also name) support to git credentials so the correct set for a repo url
> is automatically picked up by git
The "git-credential" helper needs to look at a URL like
g...@github.co
Hello
I am Zongo Daniel and work with BICIAB BANK Of Burkina Faso. I have an
important business proposal that will be of mutual benefit.
Please send me your direct number or your personal email so i can tell
you more about my proposal. It is very important we communicate and
you will be very glad
On Thu, Nov 01 2018, Nicolas Mailhot wrote:
> git makes no provision for versioned release references.
>
> However, software projects need versioned releases. Software project
> integrators need versionned releases. Security auditors need versioned
> release. Software project users need versione
On Thu, Nov 01 2018, Junio C Hamano wrote:
> * ab/push-dwim-dst (2018-10-29) 9 commits
> - SQUASH???
> - push doc: document the DWYM behavior pushing to unqualified
> - push: add DWYM support for "git push refs/remotes/...:"
> - push: test that doesn't DWYM if is unqualified
> - push: ad
Hi,
git makes no provision for versioned release references.
However, software projects need versioned releases. Software project
integrators need versionned releases. Security auditors need versioned
release. Software project users need versioned releases.
Versioned releases are not the same th
Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
From: Steve Hoelzer
From Visual Studio 2015 Code Analysis: Warning C28159 Consider using
'GetTickCount64' instead of 'GetTickCount'.
Reason: GetTickCount() overflows roughly every 49 days. Code that does
not take that into account c
Hi,
A dev persona is not just a username, please add email (and probably
also name) support to git credentials so the correct set for a repo url
is automatically picked up by git
Regards,
--
Nicolas Mailhot
1 - 100 of 103 matches
Mail list logo
