Allows the user to verify and/or change the contents of the merge
before committing as necessary
Signed-off-by: Mike Lewis
---
contrib/subtree/git-subtree.sh | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/gi
On Mon, Mar 20, 2017 at 9:25 PM, Michael Haggerty wrote:
> Instead of moving all of the `for_each_*_submodule()` functions over, I
> encourage you to consider getting rid of them entirely and let the
> end-users call the `refs_for_each_*()` versions of the functions. Again,
> I'm not sure that the
As per the discussion about use of "git name-rev" vs "git symbolic-ref" in
git-p4 here:
http://marc.info/?l=git&m=148979063421355
git-p4 could get confused about the branch it is on and affects
the git-p4.allowSubmit option. This adds a failing
test case for the problem.
Luke Diamand (1):
git
Using name-rev to find the current git branch means that git-p4
does not correctly get the current branch name if there are
multiple branches pointing at HEAD, or a tag.
This change adds a test case which demonstrates the problem.
Configuring which branches are allowed to be submitted from goes
wr
This v2 addresses the feedback on my "rev-parse: match @{u}, @{push}
and ^{} case-insensitively" patch. I've split this into a 3
patch series:
Ævar Arnfjörð Bjarmason (3):
rev-parse: match @{upstream}, @{u} and @{push} case-insensitively
Reworded the documentation as Junio suggested in
.
rev
Add @{p} as a shorthand for @{push} for consistency with the @{u}
shorthand for @{upstream}.
This wasn't added when @{push} was introduced in commit
adfe5d0434 ("sha1_name: implement @{push} shorthand", 2015-05-21), but
it can be added without any ambiguity and saves the user some typing.
Signed-
Change the revision parsing logic to match ^{commit}, ^{tree}, ^{blob}
etc. case-insensitively.
Before this change supplying anything except the lower-case forms
emits an "unknown revision or path not in the working tree"
error. This change makes upper-case & mixed-case versions equivalent
to the
Change the revision parsing logic to match @{upstream}, @{u} & @{push}
case-insensitively.
Before this change supplying anything except the lower-case forms
emits an "unknown revision or path not in the working tree"
error. This change makes upper-case & mixed-case versions equivalent
to the lower
Am 25.03.2017 um 22:11 schrieb Jeff King:
> The most correct way is that the caller of log_write_email_headers() and
> diff_flush() should have a function-local strbuf which holds the data,
> gets passed to diff_flush() as some kind opaque context, and then is
> freed afterwards. We don't have such
FreeBSD implements getcwd(3) as a syscall, but falls back to a version
based on readdir(3) if it fails for some reason. The latter requires
permissions to read and execute path components, while the former does
not. That means that if our buffer is too small and we're missing
rights we could get
Convert this function pointer type and the functions that implement it
to take a struct object_id. Introduce a temporary in
show_ambiguous_object to avoid having to convert for_each_abbrev at this
point.
Signed-off-by: brian m. carlson
---
sha1_name.c | 64 --
Signed-off-by: brian m. carlson
---
parse-options-cb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/parse-options-cb.c b/parse-options-cb.c
index b7d8f7dcb2..40ece4d8c2 100644
--- a/parse-options-cb.c
+++ b/parse-options-cb.c
@@ -96,7 +96,7 @@ int parse_opt_commits(co
This is part 7 in the continuing transition to use struct object_id.
This series focuses on two main areas: adding two constants for the
maximum hash size we'll be using (which will be suitable for allocating
memory) and converting struct sha1_array to struct oid_array.
The rationale for adding s
Convert the callers to pass struct object_id by changing the function
declaration and definition and applying the following semantic patch:
@@
expression E1, E2, E3;
@@
- sha1_array_append(E1, E2[E3].hash)
+ sha1_array_append(E1, E2 + E3)
@@
expression E1, E2;
@@
- sha1_array_append(E1, E2.hash)
Convert this function by changing the declaration and definition and
applying the following semantic patch to update the callers:
@@
expression E1, E2;
@@
- sha1_array_lookup(E1, E2.hash)
+ sha1_array_lookup(E1, &E2)
@@
expression E1, E2;
@@
- sha1_array_lookup(E1, E2->hash)
+ sha1_array_lookup(E
Convert a hardcoded constant buffer size to a use of GIT_MAX_HEXSZ, and
use parse_oid_hex to reduce the dependency on the size of the hash.
This function is a caller of sha1_array_append, which will be converted
later.
Signed-off-by: brian m. carlson
---
fsck.c | 11 ++-
1 file changed,
Since the structure and functions have changed names, update the code
examples and the documentation. Rename the file to match the new name
of the API.
Signed-off-by: brian m. carlson
---
.../{api-sha1-array.txt => api-oid-array.txt} | 44 +++---
1 file changed, 22 insertio
This helper is very small, so convert the entire thing.
Signed-off-by: brian m. carlson
---
t/helper/test-sha1-array.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/helper/test-sha1-array.c b/t/helper/test-sha1-array.c
index f7a53c4ad6..b4bb97fccc 100644
--- a/
There are a very small number of callers which don't already use struct
object_id. Convert them.
Signed-off-by: brian m. carlson
---
bisect.c | 14 +++---
builtin/pack-objects.c | 16
ref-filter.c | 22 +++---
3 files changed, 26
Convert the caller of sha1_array_append to struct object_id.
Signed-off-by: brian m. carlson
---
builtin/pull.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/pull.c b/builtin/pull.c
index 3ecb881b0b..a9f7553f30 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
Make sha1_array_for_each_unique take a callback using struct object_id.
Since one of these callbacks is an argument to for_each_abbrev, convert
those as well. Rename various functions, replacing "sha1" with "oid".
Signed-off-by: brian m. carlson
---
builtin/cat-file.c | 4 ++--
builtin
Convert some hardcoded constants into uses of parse_oid_hex.
Additionally, convert all uses of struct command, and miscellaneous
other functions necessary for that. This work is necessary to be able
to convert sha1_array_append later on.
To avoid needing to specify a constant, reject shallow line
Since this structure handles an array of object IDs, rename it to struct
oid_array. Also rename the accessor functions and the initialization
constant.
This commit was produced mechanically by providing non-Documentation
files to the following Perl one-liners:
perl -pi -E 's/struct sha1_arra
Convert virtually all uses of unsigned char [20] to struct object_id.
Leave all the arguments that come from struct sha1_array, as these will
be converted in a later patch.
Signed-off-by: brian m. carlson
---
builtin/pull.c | 72 +-
1 file
Since we will want to transition to a new hash at some point in the
future, and that hash may be larger in size than 160 bits, introduce two
constants that can be used for allocating a sufficient amount of memory.
They can be increased to reflect the largest supported hash size.
Signed-off-by: bri
Since we will likely be introducing a new hash function at some point,
and that hash function might be longer than 40 hex characters, use the
constant GIT_MAX_HEXSZ, which is designed to be suitable for
allocations, instead of GIT_SHA1_HEXSZ. This will ease the transition
down the line by distingu
Signed-off-by: brian m. carlson
---
builtin/diff.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/builtin/diff.c b/builtin/diff.c
index 3d64b85337..398eee00d5 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -21,7 +21,7 @@
#define DIFF
If we had already processed the last newline in a push certificate, we
would end up subtracting NULL from the end-of-certificate pointer when
computing the length of the line. This would have resulted in an
absurdly large length, and possibly a buffer overflow. Instead,
subtract the beginning-of-
Make the internal storage for struct sha1_array use an array of struct
object_id internally. Update the users of this struct which inspect its
internals.
Signed-off-by: brian m. carlson
---
bisect.c | 14 +++---
builtin/pull.c | 22 +++---
builtin/r
Convert struct disambiguate_state to use struct object_id by changing
the structure definition and applying the following semantic patch:
@@
struct disambiguate_state E1;
@@
- E1.bin_pfx
+ E1.bin_pfx.hash
@@
struct disambiguate_state *E1;
@@
- E1->bin_pfx
+ E1->bin_pfx.hash
@@
struct disambiguat
Since we will likely be introducing a new hash function at some point,
and that hash function might be longer than 20 bytes, use the constant
GIT_MAX_RAWSZ, which is designed to be suitable for allocations, instead
of GIT_SHA1_RAWSZ. This will ease the transition down the line by
distinguishing be
All of the callers of this function have been converted, so convert this
function and update the callers. This function also calls
sha1_array_append, which we'll convert shortly.
Signed-off-by: brian m. carlson
---
builtin/fetch.c | 6 +++---
submodule.c | 4 ++--
submodule.h | 2 +-
3
مساء الخير
بتاريخ 25/3/2017، كتب Google+ (Hugo R3s3nd3 BeZaInA)
:
> نشر Hugo R3s3nd3 BeZaInA مشاركة مع Resurrection Remix. عرض:
> https://plus.google.com/_/notifications/emlink?emr=15213587310654228599&emid=COiM8rO_8tICFcagHgodYCgCMA&path=%2F102357686384107376925%2Fposts%2FTfsFVEa6BpS&dt=
On 03/25/2017 07:12 PM, Daniel Ferreira wrote:
> Create an option for the dir_iterator API to iterate over a directory
> path only after having iterated through its contents. This feature was
> predicted, although not implemented by 0fe5043 ("dir_iterator: new API
> for iterating over a directory t
On 03/25/2017 07:12 PM, Daniel Ferreira wrote:
> Create an option for the dir_iterator API to iterate over a directory
> path only after having iterated through its contents. This feature was
> predicted, although not implemented by 0fe5043 ("dir_iterator: new API
> for iterating over a directory t
Jean-Noël AVILA writes:
> ... So I would
> think the other way around: for those interested in translated the
> documentation, some script would allow to checkout the git project inside the
> gitman-l10n project (like a kind of library).
>
> This would be mainly transparent for the git develop
Brandon Williams writes:
> On 03/24, Junio C Hamano wrote:
>> * bw/recurse-submodules-relative-fix (2017-03-17) 5 commits
>> - ls-files: fix bug when recursing with relative pathspec
>> - ls-files: fix typo in variable name
>> - grep: fix bug when recursing with relative pathspec
>> - setup:
Luke Diamand writes:
> As per the discussion about use of "git name-rev" vs "git symbolic-ref" in
> git-p4 here:
>
> http://marc.info/?l=git&m=148979063421355
>
> git-p4 could get confused about the branch it is on and affects
> the git-p4.allowSubmit option. This adds a failing
> test case for
Jeff King writes:
> On Fri, Mar 24, 2017 at 11:37:54PM -0700, Junio C Hamano wrote:
>
>> The hash that names a packfile is constructed by sorting all the
>> names of the objects contained in the packfile and running SHA-1
>> hash over it. I think this MUST be hashed with collision-attack
>> dete
Setup
Version : git version 2.12.1.windows.1
OS Version : Microsoft Windows [Version 10.0.14393]
Options
$ cat /etc/install-options.txt
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Crede
Ævar Arnfjörð Bjarmason writes:
> The ^{} suffix could be changed to be case-insensitive as well
> without introducing any ambiguities. That was included in an earlier
> version of this patch, but Junio objected to its inclusion in [2].
We try not to be personal in our log message. It's not li
Ævar Arnfjörð Bjarmason writes:
> Change the revision parsing logic to match ^{commit}, ^{tree}, ^{blob}
> etc. case-insensitively.
>
> Before this change supplying anything except the lower-case forms
> emits an "unknown revision or path not in the working tree"
> error. This change makes upper
René Scharfe writes:
> FreeBSD implements getcwd(3) as a syscall, but falls back to a version
> based on readdir(3) if it fails for some reason. The latter requires
> permissions to read and execute path components, while the former does
> not. That means that if our buffer is too small and we'
Johannes Schindelin writes:
>> Making "flags" unsigned was a correct change, but this is now wrong,
>> as "allow" is made unsigned by accident.
> ...
>
> Your patch looks good, you could do even better by reverting that move
> (IIRC it was at the end of the line, and it was set to 0 by default).
On Sun, Mar 26, 2017 at 04:16:06PM -0700, Junio C Hamano wrote:
> > I don't think this case really matters for collision detection. What's
> > important is what Git does when it receives a brand-new packfile that
> > would overwrite an existing one. It _should_ keep the old one, under the
> > usua
On Sun, Mar 26, 2017 at 12:16:53PM +, Ævar Arnfjörð Bjarmason wrote:
> Add @{p} as a shorthand for @{push} for consistency with the @{u}
> shorthand for @{upstream}.
>
> This wasn't added when @{push} was introduced in commit
> adfe5d0434 ("sha1_name: implement @{push} shorthand", 2015-05-21)
On Sun, Mar 26, 2017 at 05:36:21PM -0700, Junio C Hamano wrote:
> It's not "potential confusion". This closes the door for us to
> introduce "TREE" as a separate object type in the future.
>
> If we agree to make a declaration that all typenames are officially
> spelled in lowercase [*1*] and at
On Sun, Mar 26, 2017 at 03:41:14PM +0200, René Scharfe wrote:
> Am 25.03.2017 um 22:11 schrieb Jeff King:
> > The most correct way is that the caller of log_write_email_headers() and
> > diff_flush() should have a function-local strbuf which holds the data,
> > gets passed to diff_flush() as some
Jeff King writes:
> FWIW, I cannot see us ever adding TREE (or Tree) as a separate type.
> It's too confusing for no gain. We'd call it "tree2" or something more
> obvious.
In case it was not clear, I didn't mean to say I _want_ to leave
that door open. Well, I cannot imagine it was unclear, as
BongHo Lee writes:
> If I add --no-ff option, it works properly.
> I think --no-commit option should be worked without --no-ff.
It is understandable that this is confusing, but --no-commit is an
instruction not to create a new commit object. As fast-forwarding
to the commit that is a strict des
Od: "Junio C Hamano"
Do: "René Scharfe" ;
Wysłane: 2:40 Poniedziałek 2017-03-27
Temat: Re: [PATCH] strbuf: support long paths w/o read rights in
strbuf_getcwd() on FreeBSD
>
> Nicely analysed and fixed (or is the right word "worked around"?)
>
> Thanks, will queue.
>
Is this patch going to
Jeff King writes:
>> If a malicious site can craft two packfiles that hash to the same,
>> then it can first feed one against a fetch request, then feed the
>> other one when a later fetch request comes, and then the later pack
>> is discarded by the "existing data wins" rule. Even though this
>
On 27 March 2017 at 00:18, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> As per the discussion about use of "git name-rev" vs "git symbolic-ref" in
>> git-p4 here:
>>
>> http://marc.info/?l=git&m=148979063421355
>>
>> git-p4 could get confused about the branch it is on and affects
>> the git-
53 matches
Mail list logo
