Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3a85a02a77..5d06aa9c98 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const
Both functions that are updated in this commit are called by
verify_absent(), which is part of the "unpack-trees" operation that is
supposed to work on any index file specified by the caller. Thanks to
Brandon [1] [2], an implicit dependency on the_index is exposed. This
commit fixes it.
In both
This function mark_new_skip_worktree() has an argument named the_index
which is also the name of a global variable. While they have different
types (the global the_index is not a pointer) mistakes can easily
happen and it's also confusing for readers. Rename the function
argument to something
v2 fixes an incorrect patch splitting (I should have built one more
time :P) between 3/5 and 4/5. v1's 6/6 is dropped. Brandon suggested a
better way of doing it which may happen later.
Nguyễn Thái Ngọc Duy (5):
unpack-trees: remove 'extern' on function declaration
unpack-trees: add a note
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/unpack-trees.h b/unpack-trees.h
index c2b434c606..534358fcc5 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -82,8 +82,8 @@ struct unpack_trees_options {
Prior to fba92be8f7, this code implicitly (and incorrectly) assumes
the_index when running the exclude machinery. fba92be8f7 helps show
this problem clearer because unpack-trees operation is supposed to
work on whatever index the caller specifies... not specifically
the_index.
Update the code to
On Tue, Jun 5, 2018 at 6:58 PM, Brandon Williams wrote:
> On 06/05, Nguyễn Thái Ngọc Duy wrote:
>> Use of global variables like the_index makes it very hard to follow
>> the code flow, especially when it's buried deep in some minor helper
>> function.
>>
>> We are gradually avoiding global
On Tue, Jun 5, 2018 at 5:37 PM, Jonathan Nieder wrote:
>> This patch is written to be more easily reviewed: static functions are
>> moved verbatim from fetch-pack.c to negotiator/default.c, and it can be
>> seen that the lines replaced by negotiator->X() calls are present in the
>> X() functions
On Tue, Jun 5, 2018 at 5:01 PM, Jonathan Nieder wrote:
> I like it. I think it should be possible to describe the benefit of
> this patch without reference to the specifics of the subsequent one.
> Maybe something like:
>
> When receiving 'ACK continue' for a common commit,
>
On Tue, Jun 5, 2018 at 4:35 PM, Jonathan Nieder wrote:
> Jonathan Tan wrote:
>
>> Reduce the number of global variables by making the priority queue and
>> the count of non-common commits in it local, passing them as a struct to
>> various functions where necessary.
>
> \o/
>
>> This also helps
On Tue, Jun 5, 2018 at 4:30 PM, Jonathan Nieder wrote:
> I get lost in the above description. I suspect it's doing a good job
> of describing the code, instead of answering the question I really
> have about what is broken and what behavior we want instead.
>
> E.g. are there some commands that
Jonathan Tan wrote:
> Introduce the new files fetch-negotiator.{h,c}, which contains an API
> behind which the details of negotiation are abstracted. Currently, only
> one algorithm is available: the existing one.
>
> This patch is written to be more easily reviewed: static functions are
> moved
On Tue, 5 Jun 2018 16:16:34 -0700
Jonathan Nieder wrote:
> Hi,
>
> Jonathan Tan wrote:
>
> > When "ACK %s ready" is received, find_common() clears rev_list in an
> > attempt to stop further "have" lines from being sent [1]. This appears
> > to work, despite the invocation to mark_common() in
On Tue, 5 Jun 2018 16:08:21 -0700
Jonathan Nieder wrote:
> Hi,
>
> Jonathan Tan wrote:
>
> > If tag following is required when using a transport that does not
> > support tag following, fetch_pack() will be invoked twice in the same
> > process, necessitating a clearing of the object flags
Hi,
Jonathan Tan wrote:
> This enables the calculation of was_common and the invocation to
> mark_common() to be abstracted into a single call to the negotiator API
> (to be introduced in a subsequent patch).
I like it. I think it should be possible to describe the benefit of
this patch
Jonathan Tan wrote:
> Reduce the number of global variables by making the priority queue and
> the count of non-common commits in it local, passing them as a struct to
> various functions where necessary.
\o/
> This also helps in the case that fetch_pack() is invoked twice in the
> same process
Hi,
Jonathan Tan wrote:
> In do_fetch_pack_v2(), rev_list_insert_ref_oid() is invoked before
> everything_local(). This means that if we have a commit that is both our
> ref and their ref, it would be enqueued by rev_list_insert_ref_oid() as
> SEEN, and since it is thus already SEEN,
Jonathan Nieder wrote:
> Jonathan Tan wrote:
>> The corresponding code for protocol v2 in process_acks() does not have
>> the same problem, because the invoker of process_acks()
>> (do_fetch_pack_v2()) proceeds immediately to processing the packfile
>
> nit: s/proceeds/procedes/
Whoops. My
Hi,
Jonathan Tan wrote:
> When "ACK %s ready" is received, find_common() clears rev_list in an
> attempt to stop further "have" lines from being sent [1]. This appears
> to work, despite the invocation to mark_common() in the "while" loop.
Does "appears to work" mean "works" or "doesn't work
Hi,
Jonathan Tan wrote:
> If tag following is required when using a transport that does not
> support tag following, fetch_pack() will be invoked twice in the same
> process, necessitating a clearing of the object flags used by
> fetch_pack() sometime during the second invocation. This is
ATENÇÃO;
Sua caixa de correio excedeu o limite de armazenamento, que é de 5 GB como
definido pelo administrador, que está atualmente em execução no 10.9GB, você
pode não ser capaz de enviar ou receber novas mensagens até que você re-validar
a sua caixa de correio. Para revalidar sua caixa de
On Tue, Jun 5, 2018 at 2:33 PM Heinz, Steve wrote:
>
> Hi.
>
> I am new to Git and have read quite a few articles on it.
> I am planning on setting up a remote repository on a windows 2012 R2 server
> and will access it via HTTPS.
> I am setting up a local repository on my desk top (others in my
On June 5, 2018 5:24 PM, Steve Heinz wrote:
> I am new to Git and have read quite a few articles on it.
> I am planning on setting up a remote repository on a windows 2012 R2
server
> and will access it via HTTPS.
> I am setting up a local repository on my desk top (others in my group will
do
>
On 5 June 2018 at 20:41, Eric Sunshine wrote:
> On Tue, Jun 5, 2018 at 6:56 AM Luke Diamand wrote:
>> On 5 June 2018 at 10:54, Eric Sunshine wrote:
>> > On Tue, Jun 5, 2018 at 5:14 AM Luke Diamand wrote:
>> >> +m = re.search('Too many rows scanned \(over
>> >> (\d+)\)',
When performing tag following, in addition to using the server's
"include-tag" capability to send tag objects (and emulating it if the
server does not support that capability), "git fetch" relies upon the
presence of refs/tags/* entries in the initial ref advertisement to
locally create refs
> Test t5702-protocol-v2.sh doesn't pass with this patch.
Good catch - I've fixed that.
> This is difficult...Really I don't think the default should be to follow
> tags. Mostly because this defeats the purpose of ref filtering when a
> user only requests the master branch. Now instead of the
Extend the protocol v2 tests to also test fetches with multiple refspecs
specified. This also covers the previously uncovered cases of fetching
with prefix matching and fetching by SHA-1.
Signed-off-by: Jonathan Tan
---
t/t5702-protocol-v2.sh | 47 ++
1
Hi.
I am new to Git and have read quite a few articles on it.
I am planning on setting up a remote repository on a windows 2012 R2 server and
will access it via HTTPS.
I am setting up a local repository on my desk top (others in my group will do
the same).
On "server1": I install Git and
On 06/05, Jonathan Tan wrote:
> When performing tag following, in addition to using the server's
> "include-tag" capability to send tag objects (and emulating it if the
> server does not support that capability), "git fetch" relies upon the
> presence of refs/tags/* entries in the initial ref
On 06/05, Jonathan Tan wrote:
> When performing tag following, in addition to using the server's
> "include-tag" capability to send tag objects (and emulating it if the
> server does not support that capability), "git fetch" relies upon the
> presence of refs/tags/* entries in the initial ref
After the events that led up to Jonathan Nieder's patch fixing fetch by
SHA-1 in protocol v2 [1], while expanding protocol v2's test coverage, I
found a bug with tag following. Patch 2 is a patch that fixes that bug
(and patch 1 is a related but independent test that I had written
beforehand).
Extend the protocol v2 tests to also test fetches with multiple refspecs
specified. This also covers the previously uncovered cases of fetching
with prefix matching and fetching by SHA-1.
Signed-off-by: Jonathan Tan
---
t/t5702-protocol-v2.sh | 47 ++
1
When performing tag following, in addition to using the server's
"include-tag" capability to send tag objects (and emulating it if the
server does not support that capability), "git fetch" relies upon the
presence of refs/tags/* entries in the initial ref advertisement to
locally create refs
Factor out the handle_conflict function, which handles a single
conflict in a path. This is a preparation for the next step, where
this function will be re-used. No functional changes intended.
Signed-off-by: Thomas Gummerer
---
rerere.c | 143
Documentation/CodingGuidelines mentions that error messages should be
lowercase. Prior to marking them for translation follow that pattern
in rerere as well.
Signed-off-by: Thomas Gummerer
---
rerere.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
Currently when a user doesn't resolve a conflict in a file, but
commits the file with the conflict markers, and later the file ends up
in a state in which rerere can't handle it, subsequent rerere
operations that are interested in that path, such as 'rerere clear' or
'rerere forget ' will fail, or
'git rerere' is considered a plumbing command and as such its output
should be translated. Its functionality is also only enabled through
a config setting, so scripts really shouldn't rely on its output
either way.
Signed-off-by: Thomas Gummerer
---
builtin/rerere.c | 4 +--
rerere.c
Currently when a user doesn't resolve a conflict, commits the results,
and does an operation which creates another conflict, rerere will use
the ID of the previously unresolved conflict for the new conflict.
This is because the conflict is kept in the MERGE_RR file, which
'rerere' reads every time
We currently return the exact number of conflict hunks a certain path
has from the 'handle_paths' function. However all of its callers only
care whether there are conflicts or not or if there is an error.
Return only that information, and document that only that information
is returned. This
The previous round was at
<20180520211210.1248-1-t.gumme...@gmail.com>.
Thanks Junio for the comments on the previous round.
Changes since v2:
- lowercase the first letter in some error/warning messages before
marking them for translation
- wrap paths in output in single quotes, for
Currently rerere can't handle nested conflicts and will error out when
it encounters such conflicts. Do that by recursively calling the
'handle_conflict' function to normalize the conflict.
The conflict ID calculation here deserves some explanation:
As we are using the same handle_conflict
It looks like most paths in the output in the git codebase are wrapped
in single quotes. Standardize on that in rerere as well.
Apart from being more consistent, this also makes some of the strings
match strings that are already translated in other parts of the
codebase, thus reducing the work
Add some documentation for the logic behind the conflict normalization
in rerere.
Helped-by: Junio C Hamano
Signed-off-by: Thomas Gummerer
---
Documentation/technical/rerere.txt | 142 +
rerere.c | 4 -
2 files changed, 142 insertions(+),
We have multiple different variants of the error message we show to
the user if 'read_cache' fails. The "Could not read index" variant we
are using in 'rerere.c' is currently not used anywhere in translated
form.
As a subsequent commit will mark all output that comes from 'rerere.c'
for
On Tue, Jun 05, 2018 at 06:05:56PM +0200, Duy Nguyen wrote:
> A better option may be making git-pull accept those options as well. I
> see no reason git-pull should support options that git-fetch does (at
> least most of them).
I sent this as a RFC, mostly to discuss what is the correct path to
On 06/05, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>
> > --- i/Documentation/config.txt
> > +++ w/Documentation/config.txt
> > @@ -3327,13 +3327,13 @@ submodule..ignore::
> > submodule..active::
> > Boolean value indicating if the submodule is of interest to git
> > commands.
Jonathan Nieder wrote:
> --- i/Documentation/config.txt
> +++ w/Documentation/config.txt
> @@ -3327,13 +3327,13 @@ submodule..ignore::
> submodule..active::
> Boolean value indicating if the submodule is of interest to git
> commands. This config option takes precedence over the
> -
On 06/05, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Jun 05 2018, Brandon Williams wrote:
>
> > Add a link to gitsubmodules(7) under the `submodule.active` entry in
> > git-config(1).
>
> Did you mean to change either the subject or content of this patch? Your
> subject says gitsubmodules(7),
Hi,
Brandon Williams wrote:
> Add a link to gitsubmodules(7) under the `submodule.active` entry in
> git-config(1).
>
> Signed-off-by: Brandon Williams
> ---
> Documentation/config.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/config.txt
On Tue, Jun 05 2018, Brandon Williams wrote:
> Add a link to gitsubmodules(7) under the `submodule.active` entry in
> git-config(1).
Did you mean to change either the subject or content of this patch? Your
subject says gitsubmodules(7), but you link to git-submodule(1).
On Tue, Jun 05 2018, Brandon Williams wrote:
> +uploadpack.allowRefInWant::
> + If this option is set, `upload-pack` will support the `ref-in-want`
> + feature of the protocol version 2 `fetch` command.
> +
I think it makes sense to elaborate a bit on what this is for. Having
read this
Add a link to gitsubmodules(7) under the `submodule.active` entry in
git-config(1).
Signed-off-by: Brandon Williams
---
Documentation/config.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index
On 5 June 2018 at 21:58, Brandon Williams wrote:
> On 06/05, Ævar Arnfjörð Bjarmason wrote:
>> Since Martin & Brandon both liked this direction I've fixed it
>> up.
>>
>> Martin: I didn't want to be the author of the actual fix for the bug
>> you found, so I rewrote your commit in 3/3. The diff
From: Martin Ågren
We allocate a `struct refspec_item` on the stack without initializing
it. In particular, its `dst` and `src` members will contain some random
data from the stack. When we later call `refspec_item_clear()`, it will
call `free()` on those pointers. So if the call to
On 06/05, Ævar Arnfjörð Bjarmason wrote:
> Since Martin & Brandon both liked this direction I've fixed it
> up.
>
> Martin: I didn't want to be the author of the actual fix for the bug
> you found, so I rewrote your commit in 3/3. The diff is different, and
> I slightly modified the 3rd paragraph
Since Martin & Brandon both liked this direction I've fixed it
up.
Martin: I didn't want to be the author of the actual fix for the bug
you found, so I rewrote your commit in 3/3. The diff is different, and
I slightly modified the 3rd paragraph of the commit message & added my
sign-off, but
Re-add the non-fatal version of refspec_item_init_or_die() renamed
away in an earlier change to get a more minimal diff. This should be
used by callers that have their own error handling.
This new function could be marked "static" since nothing outside of
refspec.c uses it, but expecting future
Rename the refspec_item_init() function introduced in
6d4c057859 ("refspec: introduce struct refspec", 2018-05-16) to
refspec_item_init_or_die().
This follows the convention of other *_or_die() functions, and is done
in preparation for making it a wrapper for a non-fatal variant.
Signed-off-by:
On Tue, Jun 5, 2018 at 6:59 AM Luke Diamand wrote:
> On 5 June 2018 at 11:49, Merland Romain wrote:
> >> +# now check that we can actually talk to the server
> >> +global p4_access_checked
> >> +if not p4_access_checked:
> >> +p4_access_checked = True
> >> +
On Tue, Jun 5, 2018 at 6:56 AM Luke Diamand wrote:
> On 5 June 2018 at 10:54, Eric Sunshine wrote:
> > On Tue, Jun 5, 2018 at 5:14 AM Luke Diamand wrote:
> >> +m = re.search('Too many rows scanned \(over (\d+)\)',
> >> data)
> >> +if not m:
> >> +
On 05/06/18 18:51, Brandon Williams wrote:
> Currently, while performing packfile negotiation, clients are only
> allowed to specify their desired objects using object ids. This causes
> a vulnerability to failure when an object turns non-existent during
> negotiation, which may happen if, for
Currently, while performing packfile negotiation, clients are only
allowed to specify their desired objects using object ids. This causes
a vulnerability to failure when an object turns non-existent during
negotiation, which may happen if, for example, the desired repository is
provided by
This series adds the ref-in-want feature which was originally proposed
by Jonathan Tan
(https://public-inbox.org/git/cover.1485381677.git.jonathanta...@google.com/).
Back when ref-in-want was first discussed it was decided that we should
first solve the issue of moving to a new wire format and
Add an 'unpack-sideband' subcommand to the test-pkt-line helper to
enable unpacking packet line data sent multiplexed using a sideband.
Signed-off-by: Brandon Williams
---
t/helper/test-pkt-line.c | 37 +
1 file changed, 37 insertions(+)
diff --git
Refactor the fetch_refs function into a function that does the fetching
of refs and another function that stores them.
Signed-off-by: Brandon Williams
---
builtin/fetch.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
Expand the transport fetch method signature, by adding an output
parameter, to allow transports to return information about the refs they
have fetched. Then communicate shallow status information through this
mechanism instead of by modifying the input list of refs.
This does require clients to
Implement ref-in-want on the client side so that when a server supports
the "ref-in-want" feature, a client will send "want-ref" lines for each
reference the client wants to fetch.
Signed-off-by: Brandon Williams
---
fetch-pack.c | 35 +++---
On Tue, Jun 05, 2018 at 12:02:12PM -0400, Sean Hunt wrote:
> I would like to see the source code to git checkout --orphan so I can
> learn how it works and so I can manually do what it does by hand on
> making a new branch with no history in the refs folder. I can only do
> it on my iPhone as my
Refactor find_non_local_tags and get_ref_map to only take the
information they need instead of the entire transport struct. Besides
improving code clarity, this also improves their flexibility, allowing
for a different set of refs to be used instead of relying on the ones
stored in the transport
Add tests to check the behavior of fetching from a repository which
changes between rounds of negotiation (for example, when different
servers in a load-balancing agreement participate in the same stateless
RPC negotiation). This forms a baseline of comparison to the ref-in-want
functionality
Populate peer ref OIDs in get_ref_map instead of do_fetch. Besides
tightening scopes of variables in the code, this also prepares for
get_ref_map being able to be called multiple times within do_fetch.
Signed-off-by: Brandon Williams
---
builtin/fetch.c | 36 ++--
On 05/06/18 16:43, Nguyễn Thái Ngọc Duy wrote:
> Prior to fba92be8f7, this code implicitly (and incorrectly) assumes
> the_index when running the exclude machinery. fba92be8f7 helps show
> this problem clearer because unpack-trees operation is supposed to
> work on whatever index the caller
On 05/06/18 16:43, Nguyễn Thái Ngọc Duy wrote:
> This function mark_new_skip_worktree() has an argument named the_index
> which is also the name of a global variable. While they have different
> types (the global the_index is not a pointer) mistakes can easily
> happen and it's also confusing
I would like to see the source code to git checkout --orphan so I can learn how
it works and so I can manually do what it does by hand on making a new branch
with no history in the refs folder. I can only do it on my iPhone as my laptop
has no internet or way to do it there, and the program on
On 06/05, Nguyễn Thái Ngọc Duy wrote:
> Use of global variables like the_index makes it very hard to follow
> the code flow, especially when it's buried deep in some minor helper
> function.
>
> We are gradually avoiding global variables, this hopefully will make
> it one step closer. The end
On 6/5/2018 10:51 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Jun 4, 2018 at 6:52 PM, Derrick Stolee wrote:
Thanks for the feedback on v3. There were several small cleanups, but
perhaps the biggest change is the addition of "commit-graph: use
string-list API for input" which makes
From: Jeff Hostetler
Add a series of jw_ routines and "struct json_writer" structure to compose
JSON data. The resulting string data can then be output by commands wanting
to support a JSON output format.
The json-writer routines can be used to generate structured data in a
JSON-like format.
From: Jeff Hostetler
Test json-writer output using Python.
Signed-off-by: Jeff Hostetler
---
t/t0019-json-writer.sh | 38 ++
t/t0019/parse_json_1.py | 35 +++
2 files changed, 73 insertions(+)
create mode 100644
From: Jeff Hostetler
Here is V7 of my json-writer patches. Please replace the existing V5/V6
version of jh/json-writer branch with this one.
This version cleans up the die()-vs-BUG() issue that Duy mentioned recently.
It also fixes a formatting bug when composing empty sub-objects/-arrays.
It
On 06/04, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Jun 04 2018, Martin Ågren wrote:
>
> > We allocate a `struct refspec_item` on the stack without initializing
> > it. In particular, its `dst` and `src` members will contain some random
> > data from the stack. When we later call
On Mon, Jun 4, 2018 at 11:50 PM, Rafael Ascensão wrote:
> `git pull` understands some options of `git fetch` which then uses in
> its operation. The documentation of `git pull` doesn't reflect this
> clearly, showing options that are not yet supported (e.g. `--deepen`)
> and omitting options that
> diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
> index 3e5ac81bd2..ed32828105 100755
> --- a/t/t2024-checkout-dwim.sh
> +++ b/t/t2024-checkout-dwim.sh
> @@ -23,6 +23,12 @@ test_branch_upstream () {
> test_cmp expect.upstream actual.upstream
> }
>
>
This function mark_new_skip_worktree() has an argument named the_index
which is also the name of a global variable. While they have different
types (the global the_index is not a pointer) mistakes can easily
happen and it's also confusing for readers. Rename the function
argument to something
This is a potential problem that is exposed after Brandon kicked
the_index out of dir.c (big thanks!) and could be seen as a
continuation of bw/dir-c-stops-relying-on-the-index. Also thanks to
Elijah for helping analyze this code.
The last patch may be debatable. If we go this route, we may end
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/unpack-trees.h b/unpack-trees.h
index c2b434c606..534358fcc5 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -82,8 +82,8 @@ struct unpack_trees_options {
Prior to fba92be8f7, this code implicitly (and incorrectly) assumes
the_index when running the exclude machinery. fba92be8f7 helps show
this problem clearer because unpack-trees operation is supposed to
work on whatever index the caller specifies... not specifically
the_index.
Update the code to
Use of global variables like the_index makes it very hard to follow
the code flow, especially when it's buried deep in some minor helper
function.
We are gradually avoiding global variables, this hopefully will make
it one step closer. The end game is, the set of "library" source files
will have
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3a85a02a77..5d06aa9c98 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const
Both functions that are updated in this commit are called by
verify_absent(), which is part of the "unpack-trees" operation that is
supposed to work on any index file specified by the caller. Thanks to
Brandon [1] [2], an implicit dependency on the_index is exposed. This
commit fixes it.
In both
I do not know how to reproduce this (and didn't bother to look deeply
into it after I found it was not a trivial fix) but one of my "git
fetch" showed
warning: Submodule in commit be2db96a6c506464525f588da59cade0cedddb5e
at path: '(null)' collides with a submodule named the same. Skipping
it.
I
On Mon, Jun 4, 2018 at 6:52 PM, Derrick Stolee wrote:
> Thanks for the feedback on v3. There were several small cleanups, but
> perhaps the biggest change is the addition of "commit-graph: use
> string-list API for input" which makes "commit-graph: add '--reachable'
> option" much simpler.
Do
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
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
---
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 ++--
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
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
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
---
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 [...] /
Note that the "error: pathspec[...]" message is still printed. This is
because whatever else
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
Fixes issues noted with v6, hopefully ready for queuing. A tbdiff with
v6:
1: ab4529d9f5 = 1: 2ca81c76fc checkout tests: index should be clean after dwim
checkout
2: c8bbece403 = 2: 19b14a1c75 checkout.h: wrap the arguments to
unique_tracking_name()
3: 881fe63f4f = 3: 8bc6a9c052 checkout.c:
1 - 100 of 122 matches
Mail list logo
