On Sat, Jun 02, 2018 at 06:46:31AM +0200, Duy Nguyen wrote:
> > if (used_deprecated_reflog_option) {
> > - warning("the '-l' alias for '--create-reflog' is
> > deprecated;");
> > - warning("it will be removed in a future version of Git");
> > + if
--
Dear Friend,
I would like to discuss a very important issue with you. I am writing
to find out if this is your valid email. Please, let me know if this
email is valid
Kind regards
Adrien Saif
Attorney to Quatif Group of Companies
On Fri, 1 Jun 2018, Jeff King wrote:
> On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote:
>
> > $ git config --global a.b.c.d.e rday
> >
> > huh ... seemed to work fine, and added this to my ~/.gitconfig:
> >
> > [a "b.c.d"]
> > e = rday
> >
> > as i see it, the first
--
Dear Friend,
I would like to discuss a very important issue with you. I am writing
to find out if this is your valid email. Please, let me know if this
email is valid
Kind regards
Adrien Saif
Attorney to Quatif Group of Companies
On Sat, Jun 02, 2018 at 04:50:57AM -0400, Robert P. J. Day wrote:
> On Fri, 1 Jun 2018, Jeff King wrote:
>
> > On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote:
> >
> > > $ git config --global a.b.c.d.e rday
> > >
> > > huh ... seemed to work fine, and added this to my ~/.gitcon
On Fri, Jun 1, 2018 at 7:08 AM, Christian Couder
wrote:
> As there are plans to implement other ref storage systems,
> let's use a way to remove remote refs that does not depend
> on refs being files.
>
> This makes it clear to readers that this test does not
> depend on which ref backend is used.
Typo & grammar fixes suggested by Eric Sunshine. tbdiff from v5:
1: ab4529d9f5 = 1: ab4529d9f5 checkout tests: index should be clean after
dwim checkout
2: c8bbece403 = 2: c8bbece403 checkout.h: wrap the arguments to
unique_tracking_name()
3: 4fc5ab27fa ! 3: 881fe63f4f checkout.c
Internally track how many matches we find in the check_tracking_name()
callback. Nothing uses this now, but it will be made use of in a later
change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
checkout.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/checkout.c b/che
Assert that whenever there's a DWIM checkout that the index should be
clean afterwards, in addition to the correct branch being checked-out.
The way the DWIM checkout code in checkout.[ch] works is by looping
over all remotes, and for each remote trying to find if a given
reference name only exist
There is no point in doing this right now, but in later change the
"ret" variable will be inspected. This change makes that meaningful
change smaller.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/checkout.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin
As the "checkout" documentation describes:
If is not found but there does exist a tracking branch in
exactly one remote (call it ) with a matching name, treat
as equivalent to [...] /
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/config.txt | 7 +++
advice.c
Add an *_INIT macro for the tracking_name_data similar to what exists
elsewhere in the codebase, e.g. OID_ARRAY_INIT in sha1-array.h. This
will make it more idiomatic in later changes to add more fields to the
struct & its initialization macro.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
checkout
Introduce a checkout.defaultRemote setting which can be used to
designate a remote to prefer (via checkout.defaultRemote=origin) when
running e.g. "git checkout master" to mean origin/master, even though
there's other remotes that have the "master" branch.
I want this because it's very handy to us
The line was too long already, and will be longer still when a later
change adds another argument.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
checkout.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/checkout.h b/checkout.h
index 9980711179..4cd4cd1c23 100644
--- a/checkou
Pass the previously added "num_matches" struct value up to the callers
of unique_tracking_name(). This will allow callers to optionally print
better error messages in a later change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/checkout.c | 10 +++---
builtin/worktree.c | 4 ++--
chec
Derrick Stolee writes:
> While iterating through the commit parents, perform the generation
> number calculation and compare against the value stored in the
> commit-graph.
All right, that's good.
What about commit-graph files that have GENERATION_NUMBER_ZERO for all
its commits (because we ver
On Fri, Jun 1, 2018 at 7:08 AM, Christian Couder
wrote:
> test_expect_success "multi-fetch works off a 'clean' repository" '
> - rm -rf "$GIT_DIR/svn" "$GIT_DIR/refs/remotes" &&
> + rm -rf "$GIT_DIR/svn" &&
> + git for-each-ref --format="option no-deref%0adelete %(refname)"
> r
Derrick Stolee writes:
Nice and simple. The only possible question may be the ordering of
patches in the series, namely whether this change should be before or
after test checking generation numbers.
> Signed-off-by: Derrick Stolee
> ---
> commit-graph.c | 6 ++
> t/t5318-commit-
Derrick Stolee writes:
> The commit-graph file has an extra chunk to store the parent int-ids for
> parents beyond the first parent for octopus merges. Our test repo has a
> single octopus merge that we can manipulate to demonstrate the 'verify'
> subcommand detects incorrect values in that chunk
I am Ms.Ella Golan, I am the Executive Vice President Banking Division with
FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you
regarding an extremely important and urgent matter. If you would oblige me the
opportunity, I shall provide you with details upon your respons
Derrick Stolee writes:
> The commit-graph file ends with a SHA1 hash of the previous contents. If
> a commit-graph file has errors but the checksum hash is correct, then we
> know that the problem is a bug in Git and not simply file corruption
> after-the-fact.
>
> Compute the checksum right away
Derrick Stolee writes:
> If core.commitGraph is true, verify the contents of the commit-graph
> during 'git fsck' using the 'git commit-graph verify' subcommand. Run
> this check on all alternates, as well.
All right, so we have one config variable to control the use of
serialized commit-graph f
Derrick Stolee writes:
> When writing commit-graph files, it can be convenient to ask for all
> reachable commits (starting at the ref set) in the resulting file. This
> is particularly helpful when writing to stdin is complicated, such as a
> future integration with 'git gc' which will call
> wr
Derrick Stolee writes:
> The commit-graph file is a very helpful feature for speeding up git
> operations. In order to make it more useful, write the commit-graph file
> by default during standard garbage collection operations.
I think you meant here "make it possible to write the commit-graph f
Derrick Stolee writes:
> The commit-graph feature is now integrated with 'fsck' and 'gc',
> so remove those items from the "Future Work" section of the
> commit-graph design document.
It is always nice to have such commit as a summary what was done in the
series, and to have up to date roadmap.
Derrick Stolee writes:
> On 5/31/2018 10:30 PM, Junio C Hamano wrote:
>> Derrick Stolee writes:
>>
>>> Shallow clones do not interact well with the commit-graph feature for
>>> several reasons. Instead of doing the hard thing to fix those
>>> interactions, instead prevent reading or writing a com
i realize that, when you "git stash push", stash graciously saves
the branch you were on as part of the commit message, but does any
subsequent stash operation technically *need* that branch name?
it doesn't seem like it -- even "git stash branch" really only needs
the commit that was the ba
"brian m. carlson" writes:
> On Sat, May 26, 2018 at 08:46:09PM +0200, Jakub Narebski wrote:
>> One issue: in the future when Git moves to NewHash, it could encounter
>> then both commit-graph files using SHA-1 and using NewHash. What about
>> GRPH_OID_LEN then: for one of those it would be inco
--
Hello
I have been trying to contact you. Did you get my business proposal?
Best Regards,
Miss.Victoria Mehmet
On 06/02, Robert P. J. Day wrote:
>
> i realize that, when you "git stash push", stash graciously saves
> the branch you were on as part of the commit message, but does any
> subsequent stash operation technically *need* that branch name?
$ git stash list
stash@{0}: WIP on master: 4e5a9
Derrick Stolee writes:
> On 5/27/2018 6:55 PM, Jakub Narebski wrote:
>> Derrick Stolee writes:
[...]
>>> +static int verify_commit_graph_error;
>>> +
>>> +static void graph_report(const char *fmt, ...)
>>> +{
>>> + va_list ap;
>>> + struct strbuf sb = STRBUF_INIT;
>>> + verify_commit_graph_
It's been time. Thank you for parience.
Changes:
* did most of the changes proposed
* rebase to newer master (latest conflicting change is addition of combined
test helper)
* make tests which cover, hopefully, all cases.
* handle incorectly truncated input also in receive-pack. Considering the
Push passes to another commands, as described in
https://public-inbox.org/git/20171129032214.gb32...@sigill.intra.peff.net/
As it gets complicated to correctly track the data length, instead transfer
the data through parent process and cut the pipe as the specified length is
reached. Do it only wh
http-backend reads whole input until EOF. However, the RFC 3875 specifies
that a script must read only as many bytes as specified by CONTENT_LENGTH
environment variable. Web server may exercise the specification by not closing
the script's standard input after writing content. In that case http-bac
Derrick Stolee writes:
> On 5/28/2018 10:05 AM, Jakub Narebski wrote:
>> Derrick Stolee writes:
[...]
>>> diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh
>>> index 6ca451dfd2..bd64481c7a 100755
>>> --- a/t/t5318-commit-graph.sh
>>> +++ b/t/t5318-commit-graph.sh
>>> @@ -235,9 +235,
Derrick Stolee writes:
> On 5/30/2018 6:24 PM, Jakub Narebski wrote:
[...]
>> NOTE: we will be checking Commit Data chunk; I think it would be good
>> idea to verify that size of Commit Data chunk matches (N * (H + 16) bytes)
>> that format gives us, so that we don't accidentally red outside of
>
To ignore all .js file under a directory `lib', I can use "lib/**/js" to match
them. But when using git command such as "git add", using "git add lib/\*.js"
is sufficient. Why is this difference in glob mode?
I have heard that there are many different glob mode out there (e.g., bash has
many diffe
On Fri, Jun 1, 2018 at 10:03 PM, Duy Nguyen wrote:
> On Fri, Jun 1, 2018 at 8:34 PM, Elijah Newren wrote:
>> On Fri, Jun 1, 2018 at 9:11 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> This is more of a bug report than an actual fix because I'm not sure
>>> if "o->src_index" is always the correct answer
Hi, Junio
On 05/29, Eduardo Habkost wrote:
>Hi,
>
>I'm trying to use git-format-patch --base to generate the list of
>prerequisite patches for a series, but the behavior of git
>doesn't seem to match the documentation:
>
>When using a commit count (e.g.: "-2"), git-format-patch generates the
>prer
The `git merge-recursive` command allows the user to directly specify
three commits to merge -- base, head, and remote. (More than three can be
specified in the case of multiple merge bases.) Note that since the user
is allowed to specify head, it need not match HEAD.
Virtually every test and sc
`git merge-recursive` does a three-way merge between user-specified trees
base, head, and remote. Since the user is allowed to specify head, we can
not necesarily assume that head == HEAD.
We modify index_has_changes() to take an extra argument specifying the
tree to compare the index to. If NUL
Between working on some other things, I happened to be reading
Documentation/git-merge.txt and ran across the part that says:
...[merge will] abort if there are any changes registered in the
index relative to the `HEAD` commit. (One exception is when the
changed index entries are in t
According to Documentation/git-merge.txt,
...[merge will] abort if there are any changes registered in the index
relative to the `HEAD` commit. (One exception is when the changed index
entries are in the state that would result from the merge already.)
Add some tests showing that thi
t6044 has lots of tests for verifying that merge will abort as expected
when there are changes staged before the merge starts. However, it only
checked for non-zero exit code, which could mean that the merge ran to
completion with conflicts. Check that the merge was actually correctly
aborted, i.
In commit 65170c07d4 ("merge-recursive: avoid incorporating uncommitted
changes in a merge", 2017-12-21), it was noted that there was a special
case when merge-recursive didn't rely on unpack_trees() to enforce the
index == HEAD requirement, and thus that it needed to do that enforcement
itself. U
builtin/merge.c says that when we are about to perform a merge:
...the index must be in sync with the head commit. The strategies are
responsible to ensure this.
merge-recursive has always relied on unpack_trees() to enforce this
requirement, except in the case of an "Already up to date!
builtin/merge.c contains this important requirement for merge strategies:
...the index must be in sync with the head commit. The strategies are
responsible to ensure this.
However, Documentation/git-merge.txt says:
...[merge will] abort if there are any changes registered in the ind
47 matches
Mail list logo
