Dear Madam, Sir,
The 2018 Annual Conference is pleased to invite you to the international
Conference on Atlanta Human Rights Foundation, The meeting is scheduled to take
place from May 23rd-27th 2018 @ Atlanta Georgia USA. The organizing committee
is responsible for all visa arrangements to th
On Mon, Apr 23, 2018 at 11:39:11PM +, brian m. carlson wrote:
> diff --git a/cache.h b/cache.h
> index bbaf5c349a..4bca177cf3 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1008,6 +1008,11 @@ static inline void oidclr(struct object_id *oid)
> memset(oid->hash, 0, GIT_MAX_RAWSZ);
> }
>
>
On Mon, Apr 23, 2018 at 11:39:12PM +, brian m. carlson wrote:
> The head member of struct pack_info is completely unused and the
> nr_heads member is used only in one place, which is an assignment.
> Since these structure members are not useful, remove them.
If you reroll, you could add that t
On Mon, Apr 23, 2018 at 11:39:13PM +, brian m. carlson wrote:
> The tree member of struct object_context is unused except in one place
> where we write to it. Since there are no users of this member, remove
> it.
Yep. It's never used since its introduction in 573285e552 (sha1_name:
add get_sh
Since the very beginning, git status behaved differently for rename
detection than other rename aware commands like git log or git show as
it has the use of rename hard coded into it. After 5404c116aa ("diff:
activate diff.renames by default", 2016-02-25) the default behaves the
same by coincidenc
On Mon, Apr 23, 2018 at 11:39:14PM +, brian m. carlson wrote:
> The sha1 member in struct pack_entry is unused except for one instance
> in which we store a value in it. Since nobody ever reads this value,
> don't bother to compute it and remove the member from struct pack_entry.
Never used s
On Mon, Apr 23, 2018 at 11:39:18PM +, brian m. carlson wrote:
> There are several instances of the constant 20 and 20-based values in
> the packfile code. Abstract away dependence on SHA-1 by using the
> values from the_hash_algo instead.
While we're abstracting away 20. There's the only 20 l
On Mon, Apr 23, 2018 at 11:39:19PM +, brian m. carlson wrote:
> @@ -1850,7 +1852,7 @@ static int try_delta(struct unpacked *trg, struct
> unpacked *src,
> /* Now some size filtering heuristics. */
> trg_size = trg_entry->size;
> if (!trg_entry->delta) {
> - max_si
On Mon, Apr 23, 2018 at 11:39:49PM +, brian m. carlson wrote:
> Several of our shell scripts hard-code the object ID of the empty tree.
> To avoid any problems when changing hashes, compute this value on
> startup of the script. For performance, store the value in a variable
> and reuse it thr
On Mon, Apr 30, 2018 at 11:59:43PM +, brian m. carlson wrote:
> > I guess I'll be helping review this series instead :D
Overall I think this looks good.
>
> Yeah, I have code to fix that, but it's ugly.
>
> You can see the work on part2 and part3 of the test fixes, plus the
> fixes for all
On Tue, May 01 2018, Eckhard S. Maaß wrote:
> Since the very beginning, git status behaved differently for rename
> detection than other rename aware commands like git log or git show as
> it has the use of rename hard coded into it.
Can you elaborate on this? It seems initial rename detection
Hi Hannes,
On Mon, 30 Apr 2018, Johannes Sixt wrote:
> Am 30.04.2018 um 00:17 schrieb Johannes Schindelin:
> > t1406 specifically verifies that certain code paths fail with a BUG: ...
> > message.
> >
> > In the upcoming commit, we will convert that message to be generated via
> > BUG() instead
"Eckhard S. Maaß" wrote:
> Since the very beginning, git status behaved differently for rename
> detection than other rename aware commands like git log or git show as
> it has the use of rename hard coded into it.
My understanding is that the succession of events went stg like:
1) invent the r
On 4/30/2018 6:07 PM, Ævar Arnfjörð Bjarmason wrote:
Change the output emitted when an ambiguous object is encountered so
that we show tags first, then commits, followed by trees, and finally
blobs. Within each type we show objects in hashcmp(). Before this
change the objects were only ordered by
On 4/30/2018 6:07 PM, Ævar Arnfjörð Bjarmason wrote:
I started out just wanting to do 04/09 so I'd get prettier output, but
then noticed that ^{tag}, ^{commit}< ^{blob} and ^{tree} didn't behave
as expected with the disambiguation output, and that core.disambiguate
had never been documented.
Æva
On Tue, May 1, 2018 at 1:04 PM, Johannes Schindelin
wrote:
>> If SIGABRT occurs as a result of BUG(), and we know that this happens for
>> certain cases, it means we have an unfixed bug.
>
> Not in this case: The code in question is in
> https://github.com/git/git/blob/v2.17.0/t/helper/test-ref-st
On Thursday 26 April 2018 01:01 AM, Johannes Sixt wrote:
>
> Right. But I have LESS=RS because I do *not* want it to remain on screen
> by default.
>
In that case how about updating the commit message to be more clear
about it. How about,
It is possible to configure 'less', the pager, t
On Mon, Apr 30, 2018 at 12:17 AM, Johannes Schindelin
wrote:
> t1406 specifically verifies that certain code paths fail with a BUG: ...
> message.
>
> In the upcoming commit, we will convert that message to be generated via
> BUG() instead of die("BUG: ..."), which implies SIGABRT instead of a
> r
On Tue, May 01 2018, Derrick Stolee wrote:
> On 4/30/2018 6:07 PM, Ævar Arnfjörð Bjarmason wrote:
>> Since we show the commit data in the output that's nicely aligned once
>> we sort by object type. The decision to show tags before commits is
>> pretty arbitrary, but it's much less likely that we
Hi Tiago,
On Mon, 30 Apr 2018, Tiago Botelho wrote:
> On Mon, Apr 30, 2018 at 12:31 PM, Johannes Schindelin
> wrote:
> >
> >> > On Thu, 12 Apr 2018, Tiago Botelho wrote:
> >> >
> >> >> On Thu, Apr 12, 2018 at 9:58 AM, Christian Couder
> >> >> wrote:
> >> >> > On Thu, Apr 12, 2018 at 9:49 AM, Ha
On Tue, May 01, 2018 at 01:00:54PM +0200, Ævar Arnfjörð Bjarmason wrote:
> So didn't we use diff heuristics to begin with, and then regressed? I've
> only given this a skimming, but it's useful to have that sort of
> historical context mentioned explicitly with commit ids.
Sorry for not making thi
On Mon, Apr 30, 2018 at 11:50 AM, Ævar Arnfjörð Bjarmason
wrote:
> I think at this point git-subtree is widely used enough to move out of
> contrib/, maybe others disagree, but patches are always better for
> discussion that patch-less ML posts.
After narrow/partial clone becomes real, it should
On Wednesday 25 April 2018 11:55 AM, Johannes Sixt wrote:
>
> I considered -P, but thought that it would better be reserved for
> something related to "paths". We have --{html,man,info}-path, which
> would be served better with -[HMI]. That leaves --exec-path, which we
> would probably abbreviate
Hi Ævar,
On Mon, 30 Apr 2018, Ævar Arnfjörð Bjarmason wrote:
> I think at this point git-subtree is widely used enough to move out of
> contrib/, maybe others disagree, but patches are always better for
> discussion that patch-less ML posts.
Sure, it is used widely enough.
However, it flies in
On Tue, May 01, 2018 at 01:09:06PM +0200, Matthieu Moy wrote:
> That init_diff_ui_defaults() should indeed have been before
> git_config() from the beginning. My bad, I'm the one who
> misplaced it apparently :-(.
Should I have done this "bug fix" in a separate commit or mention it in
the commit m
On 4/30/2018 6:19 PM, Jakub Narebski wrote:
Derrick Stolee writes:
When running 'git branch --contains', the in_merge_bases_many()
method calls paint_down_to_common() to discover if a specific
commit is reachable from a set of branches. Commits with lower
generation number are not needed to co
On 4/30/2018 6:54 PM, Jakub Narebski wrote:
Derrick Stolee writes:
Now that we use generation numbers from the commit-graph, we must
ensure that all commits that exist in the commit-graph are loaded
from that file instead of from the object database. Since the
commit-graph file is only checked
Hi Hannes,
On Mon, 30 Apr 2018, Johannes Sixt wrote:
> Am 30.04.2018 um 05:25 schrieb Junio C Hamano:
> > * js/no-pager-shorthand (2018-04-25) 1 commit
> > - git: add -N as a short option for --no-pager
> >
> > "git --no-pager cmd" did not have short-and-sweet single letter
> > option. Now
On 4/30/2018 7:32 PM, Jakub Narebski wrote:
Derrick Stolee writes:
We now calculate generation numbers in the commit-graph file and use
them in paint_down_to_common().
Expand the section on generation numbers to discuss how the three
special generation numbers GENERATION_NUMBER_INFINITY, _ZER
A subsequent change will make use of this static function in the
get_short_oid() function, which is defined above where the
collect_ambiguous() function is now. Without this we'd then have a
compilation error due to a forward declaration.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1-name.c |
Add support for ^{tag} to the disambiguation logic. Before this ^{tag}
would simply be ignored:
$ git rev-parse e8f2^{tag}
error: short SHA1 e8f2 is ambiguous
hint: The candidates are:
hint: e8f2650052 tag v2.17.0
hint: e8f21caf94 commit 2013-06-24 - bash prompt: print uniq
This stray newline was accidentally introduced in
d2b7d9c7ed ("sha1_name: convert disambiguate_hint_fn to take
object_id", 2017-03-26).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1-name.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sha1-name.c b/sha1-name.c
index 5b93bf8da3..cd3b133aae
Change the output emitted when an ambiguous object is encountered so
that we show tags first, then commits, followed by trees, and finally
blobs. Within each type we show objects in hashcmp() order. Before
this change the objects were only ordered by hashcmp().
The reason for doing this is that th
The order in the enum might seem arbitrary, and isn't explained by
72518e9c26 ("more lightweight revalidation while reusing deflated
stream in packing", 2006-09-03) which added it, but Derrick Stolee
suggested that it's ordered topologically in
5f8b1ec1-258d-1acc-133e-a7c248b40...@gmail.com. Makes
The arguments weren't lined up with the opening parenthesis. Fixes up
code added in cff38a5e11 ("receive-pack: eliminate duplicate .have
refs", 2011-05-19).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1-array.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sha1-array.
A v2 addressing feedback so far. Comments inline per-patch.
Ævar Arnfjörð Bjarmason (12):
sha1-name.c: remove stray newline
sha1-array.h: align function arguments
No changes.
git-p4: change "commitish" typo to "committish"
New, I fixed my own "commitish" elsewhere, fixing it here in this
After the recent series of patches ^{tag} and ^{blob} now work to get
just the tags and blobs, but ^{tree} will still list any
tree-ish (commits, tags and trees).
The previous behavior was added in ed1ca6025f ("peel_onion:
disambiguate to favor tree-ish when we know we want a tree-ish",
2013-03-31
This was the only occurrence of "commitish" in the tree, but as the
log will reveal we've had others in the past. Fixes up code added in
00ad6e3182 ("git-p4: work with a detached head", 2015-11-21).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
git-p4.py | 6 +++---
1 file changed, 3 insertions(+),
The disambiguation logic had all the pieces necessary to only print
out those blobs that were ambiguous, but they hadn't been connected.
The initial logic was added in daba53aeaf ("sha1_name.c: add support
for disambiguating other types", 2012-07-02), and when the flags were
propagated in 8a10fea4
The core.disambiguate variable was added in
5b33cb1fd7 ("get_short_sha1: make default disambiguation
configurable", 2016-09-27) but never documented.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/config.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentati
Change the ^{commit} syntax to mean just commits instead of committish
for the purpose of disambiguation. Before this e8f2^{commit} would
show the v2.17.0 tag as a disambiguation candidate, but now it'll just
show ambiguous commits:
$ git rev-parse e8f2^{commit}
error: short SHA1 e8f2 is a
The SHA1 prefix 06fa currently matches no blobs in git.git. When
disambiguating short SHA1s we've been quietly ignoring the user's type
selector as a fallback mechanism, this was intentionally added in
1ffa26c461 ("get_short_sha1: list ambiguous objects on error",
2016-09-26).
I think that behavio
On 4/29/2018 5:08 AM, Jakub Narebski wrote:
Derrick Stolee writes:
While preparing commits to be written into a commit-graph file, compute
the generation numbers using a depth-first strategy.
Sidenote: for generation numbers it does not matter if we use
depth-first or breadth-first strategy,
Hi,
If "GREP_OPTIONS" is set to '--color=always' , then the git completion
send some escape characters like this :
^[[1;35;40m^[[K d^[[m^[[Kiff-files mergetool
a^[[m^[[Kdd d^[[m^[[Kiff-index mv
a^[[m^[[Kddremoved^[
On 4/29/2018 6:14 PM, Jakub Narebski wrote:
Derrick Stolee writes:
Most code paths load commits using lookup_commit() and then
parse_commit().
And this automatically loads commit graph if needed, thanks to changes
in parse_commit_gently(), which parse_commit() uses.
In some
On Tue, May 1, 2018 at 2:17 PM, Pascal Bourdier
wrote:
> Hi,
>
>
> If "GREP_OPTIONS" is set to '--color=always' , then the git completion
> send some escape characters like this :
>
> ^[[1;35;40m^[[K d^[[m^[[Kiff-files mergetool
> a^[[m^[[Kdd d^[
On 5/1/2018 7:27 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, May 01 2018, Derrick Stolee wrote:
On 4/30/2018 6:07 PM, Ævar Arnfjörð Bjarmason wrote:
Since we show the commit data in the output that's nicely aligned once
we sort by object type. The decision to show tags before commits is
pretty
On Tue, May 01 2018, Derrick Stolee wrote:
> On 5/1/2018 7:27 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Tue, May 01 2018, Derrick Stolee wrote:
>>
>>> On 4/30/2018 6:07 PM, Ævar Arnfjörð Bjarmason wrote:
Since we show the commit data in the output that's nicely aligned once
we sort by ob
Take advantage of the recent addition of support for lazy loading functions[1]
on Windows to simplify the loading of NtSetSystemInformation.
[1] db2f7c48cb (Win32: simplify loading of DLL functions, 2017-09-25)
Signed-off-by: Ben Peart
---
Notes:
Base Ref: master
Web-Diff: https://githu
The static remove_redundant() method is used to filter a list
of commits by removing those that are reachable from another
commit in the list. This is used to remove all possible merge-
bases except a maximal, mutually independent set.
To determine these commits are independent, we use a number of
Now that we use generation numbers from the commit-graph, we must
ensure that all commits that exist in the commit-graph are loaded
from that file instead of from the object database. Since the
commit-graph file is only checked if core.commitGraph is true, we
must check the default config before we
The generation number of a commit is defined recursively as follows:
* If a commit A has no parents, then the generation number of A is one.
* If a commit A has parents, then the generation number of A is one
more than the maximum generation number among the parents of A.
Add a uint32_t generat
Define compare_commits_by_gen_then_commit_date(), which uses generation
numbers as a primary comparison and commit date to break ties (or as a
comparison when both commits do not have computed generation numbers).
Since the commit-graph file is closed under reachability, we know that
all commits i
We now calculate generation numbers in the commit-graph file and use
them in paint_down_to_common().
Expand the section on generation numbers to discuss how the three
special generation numbers GENERATION_NUMBER_INFINITY, _ZERO, and
_MAX interact with other generation numbers.
Signed-off-by: Derr
Most of the changes from v4 are cosmetic, but there is one new commit:
commit: use generation number in remove_redundant()
Other changes are non-functional, but do clarify things.
Inter-diff from v4:
diff --git a/Documentation/technical/commit-graph.txt
b/Documentation/technical/commit
While preparing commits to be written into a commit-graph file, compute
the generation numbers using a depth-first strategy.
The only commits that are walked in this depth-first search are those
without a precomputed generation number. Thus, computation time will be
relative to the number of new c
Most code paths load commits using lookup_commit() and then
parse_commit(). In some cases, including some branch lookups, the commit
is parsed using parse_object_buffer() which side-steps parse_commit() in
favor of parse_commit_buffer().
With generation numbers in the commit-graph, we need to ensu
A commit A can reach a commit B only if the generation number of A
is strictly larger than the generation number of B. This condition
allows significantly short-circuiting commit-graph walks.
Use generation number for '--contains' type queries.
On a copy of the Linux repository where HEAD is cont
The containment algorithm for 'git branch --contains' is different
from that for 'git tag --contains' in that it uses is_descendant_of()
instead of contains_tag_algo(). The expensive portion of the branch
algorithm is computing merge bases.
When a commit-graph file exists with generation numbers c
The in_commit_list() method does not check the parents of
the candidate for containment in the list. Fix the comment
that incorrectly states that it does.
Reported-by: Jakub Narebski
Signed-off-by: Derrick Stolee
---
ref-filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
When running 'git branch --contains', the in_merge_bases_many()
method calls paint_down_to_common() to discover if a specific
commit is reachable from a set of branches. Commits with lower
generation number are not needed to correctly answer the
containment query of in_merge_bases_many().
Add a ne
On Tue, May 01 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Mon, 30 Apr 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> I think at this point git-subtree is widely used enough to move out of
>> contrib/, maybe others disagree, but patches are always better for
>> discussion that patch-less ML pos
"Eckhard Maaß" :
> On Tue, May 01, 2018 at 01:09:06PM +0200, Matthieu Moy wrote:
> > That init_diff_ui_defaults() should indeed have been before
> > git_config() from the beginning. My bad, I'm the one who
> > misplaced it apparently :-(.
> Should I have done this "bug fix" in a separate commit o
From: Ævar Arnfjörð Bjarmason
Here is what I mean by sorting during for_each_abbrev(). This seems to work for
me, so I don't know what the issue is with this one-pass approach.
Thanks,
-Stolee
-- >8 --
Change the output emitted when an ambiguous object is encountered so
that we show tags first
On 5/1/2018 8:36 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, May 01 2018, Derrick Stolee wrote:
How would sorting in our custom order before de-duplicating fail the
de-duplication? We will still pair identical OIDs as consecutive
elements and oid_array_for_each_unique only cares about consecutiv
On Tue, May 01 2018, Derrick Stolee wrote:
> From: Ævar Arnfjörð Bjarmason
>
> Here is what I mean by sorting during for_each_abbrev(). This seems to work
> for
> me, so I don't know what the issue is with this one-pass approach.
> [...]
> +static int sort_ambiguous(const void *a, const void *b
On 5/1/2018 9:39 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, May 01 2018, Derrick Stolee wrote:
From: Ævar Arnfjörð Bjarmason
Here is what I mean by sorting during for_each_abbrev(). This seems to work for
me, so I don't know what the issue is with this one-pass approach.
[...]
+static int s
Hi,
On Mon, 30 Apr 2018, SZEDER Gábor wrote:
> On Mon, Apr 30, 2018 at 5:25 AM, Junio C Hamano wrote:
> > * js/rebase-i-clean-msg-after-fixup-continue (2018-04-30) 4 commits
> > - rebase --skip: clean up commit message after a failed fixup/squash
> > - sequencer: always commit without editin
On Tue, May 01 2018, Derrick Stolee wrote:
> On 5/1/2018 9:39 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Tue, May 01 2018, Derrick Stolee wrote:
>>
>>> From: Ævar Arnfjörð Bjarmason
>>>
>>> Here is what I mean by sorting during for_each_abbrev(). This seems to work
>>> for
>>> me, so I don't know
On 5/1/2018 10:10 AM, Ævar Arnfjörð Bjarmason wrote:
Actually I'm having second thoughts about that and thinking I might keep
my original approach (with a better explanation).
A few more lines of code seems worthwhile in order to not break the
assumptions a documented API is making, no matter ho
Am 01.05.2018 um 13:57 schrieb Johannes Schindelin:
Hi Hannes,
On Mon, 30 Apr 2018, Johannes Sixt wrote:
Am 30.04.2018 um 05:25 schrieb Junio C Hamano:
* js/no-pager-shorthand (2018-04-25) 1 commit
- git: add -N as a short option for --no-pager
"git --no-pager cmd" did not have short-a
On 5/1/2018 8:47 AM, Derrick Stolee wrote:
The static remove_redundant() method is used to filter a list
of commits by removing those that are reachable from another
commit in the list. This is used to remove all possible merge-
bases except a maximal, mutually independent set.
To determine th
Thank you for taking a look - I think these are good questions. Please let me
know if you have further questions.
> -Original Message-
> From: Stefan Beller
> Sent: Monday, April 30, 2018 5:42 PM
> To: Jameson Miller
> Cc: git@vger.kernel.org; gits...@pobox.com; pclo...@gmail.com;
> jon
On Tue, May 1, 2018 at 5:23 AM, Matthieu Moy wrote:
> "Eckhard Maaß" :
>
>> On Tue, May 01, 2018 at 01:09:06PM +0200, Matthieu Moy wrote:
>> > That init_diff_ui_defaults() should indeed have been before
>> > git_config() from the beginning. My bad, I'm the one who
>> > misplaced it apparently :-(.
On Tue, May 01, 2018 at 02:23:51PM +0200, Matthieu Moy wrote:
> I'm fine with it as-is. Before your "fix", the config was ignored
> because overwritten by init_diff_ui_defaults() after reading the
> config, so effect of your change is indeed what the commit message
> describes.
>
> I'm often think
As discussed on the git email list [1] with the subject
"Fetching tags overwrites existing tags" there is a bug
where fetching tags can overwrite existing tags.
Ævar Arnfjörð Bjarmasono, has created a patch series [2]
which requires a '--force' flag when fetching if the user
actually wants to over
Add FILTER_REFS_REMOTE_TAGS to allow tags to be to identified as a
remote-tags and then list them without displaying refs/remote-tags.
Signed-off-by: Wink Saville
---
builtin/tag.c | 2 +-
ref-filter.c | 9 +++--
ref-filter.h | 11 ++-
3 files changed, 14 insertions(+), 8 deletio
The test adds and fetches a remote repository and then lists the
imported remote-tags verifying the correct values.
Signed-off-by: Wink Saville
---
t/t5505-remote.sh | 20
1 file changed, 20 insertions(+)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index a6c0178f3a..
When --remote-tags is passed to `git remote add` the tagopt is set to
--remote-tags and a second fetch line is added so tags are placed in
a separate hierarchy per remote.
For example:
$ git remote add -f --remote-tags gbenchmark g...@github.com:google/benchmark
Updating gbenchmark
warning:
I'm going on vacation until May 17 and will have limited connectivity.
I've created a new patch series, "Optional sub hierarchy for remote tags" [1]
that I'd appreciate comments and if someone wants to take this over
in my absence that would be great. I'd sure like to see this continue to move
forw
On Tue, May 1, 2018 at 10:58 AM, Johannes Sixt wrote:
> Am 01.05.2018 um 13:57 schrieb Johannes Schindelin:
>> On Mon, 30 Apr 2018, Johannes Sixt wrote:
>>> Am 30.04.2018 um 05:25 schrieb Junio C Hamano:
* js/no-pager-shorthand (2018-04-25) 1 commit
- git: add -N as a short option for
These patches add --progress and --dissociate options to git submodule.
The --progress option existed beforehand, but only for the update command and
it was left undocumented.
Both add and update submodule commands supported --reference, but not its pair
option --dissociate which allows for indep
--progress was missing from add command, was only in update.
Add --progress where it makes sense (both clone helper commands).
Add missing documentation entry.
Add test.
Signed-off-by: Casey Fitzpatrick
---
Documentation/git-submodule.txt | 7 +++
git-submodule.sh| 5 -
Add --dissociate option to add and update commands, both clone helper commands
that already have the --reference option --dissociate pairs with.
Add documentation.
Add tests.
Signed-off-by: Casey Fitzpatrick
---
Documentation/git-submodule.txt | 10 +-
builtin/submodule--helper.c | 1
Hi Casey,
thanks for sending those patches and improving submodules!
On Tue, May 1, 2018 at 11:09 AM, Casey Fitzpatrick wrote:
> These patches add --progress and --dissociate options to git submodule.
>
> The --progress option existed beforehand, but only for the update command and
> it was left
After the recent series of patches ^{tag} and ^{blob} now work to get
just the tags and blobs, but ^{tree} will still list any
tree-ish (commits, tags and trees).
The previous behavior was added in ed1ca6025f ("peel_onion:
disambiguate to favor tree-ish when we know we want a tree-ish",
2013-03-31
This was the only occurrence of "commitish" in the tree, but as the
log will reveal we've had others in the past. Fixes up code added in
00ad6e3182 ("git-p4: work with a detached head", 2015-11-21).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
git-p4.py | 6 +++---
1 file changed, 3 insertions(+),
The order in the enum might seem arbitrary, and isn't explained by
72518e9c26 ("more lightweight revalidation while reusing deflated
stream in packing", 2006-09-03) which added it.
Derrick Stolee suggested that it's ordered topologically in
5f8b1ec1-258d-1acc-133e-a7c248b40...@gmail.com. Makes sen
The arguments weren't lined up with the opening parenthesis. Fixes up
code added in aae0caf19e ("sha1-array.h: align function arguments",
2018-04-30).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1-array.c | 4 ++--
sha1-array.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff -
The disambiguation logic had all the pieces necessary to only print
out those blobs that were ambiguous, but they hadn't been connected.
The initial logic was added in daba53aeaf ("sha1_name.c: add support
for disambiguating other types", 2012-07-02), and when the flags were
propagated in 8a10fea4
A subsequent change will make use of this static function in the
get_short_oid() function, which is defined above where the
collect_ambiguous() function is now. Without this we'd then have a
compilation error due to a forward declaration.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1-name.c |
Change the ^{commit} syntax to mean just commits instead of committish
for the purpose of disambiguation. Before this e8f2^{commit} would
show the v2.17.0 tag as a disambiguation candidate, but now it'll just
show ambiguous commits:
$ git rev-parse e8f2^{commit}
error: short SHA1 e8f2 is a
Comments inline:
Ævar Arnfjörð Bjarmason (12):
sha1-name.c: remove stray newline
No changes.
sha1-array.h: align function arguments
Mention the correct commit to blame for disalignment in the commit
message, and also fix it in the *.c file.
git-p4: change "commitish" typo to "committish"
This stray newline was accidentally introduced in
d2b7d9c7ed ("sha1_name: convert disambiguate_hint_fn to take
object_id", 2017-03-26).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1-name.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sha1-name.c b/sha1-name.c
index 5b93bf8da3..cd3b133aae
The SHA1 prefix 06fa currently matches no blobs in git.git. When
disambiguating short SHA1s we've been quietly ignoring the user's type
selector as a fallback mechanism, this was intentionally added in
1ffa26c461 ("get_short_sha1: list ambiguous objects on error",
2016-09-26).
I think that behavio
The core.disambiguate variable was added in
5b33cb1fd7 ("get_short_sha1: make default disambiguation
configurable", 2016-09-27) but never documented.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/config.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentati
On Tue, May 1, 2018 at 11:09 AM, Casey Fitzpatrick wrote:
> --progress was missing from add command, was only in update.
> Add --progress where it makes sense (both clone helper commands).
> Add missing documentation entry.
> Add test.
Maybe:
The '--progress' was introduced in 72c5f88311d (clon
Add support for ^{tag} to the disambiguation logic. Before this ^{tag}
would simply be ignored:
$ git rev-parse e8f2^{tag}
error: short SHA1 e8f2 is ambiguous
hint: The candidates are:
hint: e8f2650052 tag v2.17.0
hint: e8f21caf94 commit 2013-06-24 - bash prompt: print uniq
Change the output emitted when an ambiguous object is encountered so
that we show tags first, then commits, followed by trees, and finally
blobs. Within each type we show objects in hashcmp() order. Before
this change the objects were only ordered by hashcmp().
The reason for doing this is that th
On Tue, May 01 2018, Johannes Schindelin wrote:
> I wonder whether `-!p` would be better/feasible?
In *nix shells `git -!p ...` unquoted will turn that !p into whatever
command you last ran that started with a "p", in my case `git -ping
8.8.8.8`. So there's a reason that's not the idiom in any *
1 - 100 of 210 matches
Mail list logo