After further investigation, it appears that ":/foo" indeed resolves to
the commit with message "foobar" (in the above example) if the commits
are not all created at the same time: e.g., by adding `sleep 1` between
the commit commands, or exporting `GIT_AUTHOR_DATE`.
This leaves only the question
On Sun, Jul 8, 2018 at 9:05 PM Eric Sunshine wrote:
>
> On Sun, Jul 8, 2018 at 10:38 PM Jacob Keller wrote:
> > On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
> > wrote:
> > > static inline int oidcmp(const struct object_id *oid1, const struct
> > > object_id *oid2)
> > > {
> > > -
On Sun, Jul 8, 2018 at 10:38 PM Jacob Keller wrote:
> On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
> wrote:
> > static inline int oidcmp(const struct object_id *oid1, const struct
> > object_id *oid2)
> > {
> > - return hashcmp(oid1->hash, oid2->hash);
> > + return
Hello,
I'm experiencing strange behavior with :/ references, which seems
to be inconsistent with the explanation in the docs on two counts.
First, sometimes the matched commit is not the youngest. Second, some
commits cannot be found at all, even if they are reachable from HEAD.
Here is a script
On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
wrote:
>
> This is the fourteenth series of patches to switch to using struct
> object_id and the_hash_algo. This series converts several core pieces
> to use struct object_id, including the oid* and hex functions.
>
> All of these patches have
On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
wrote:
> static inline int oidcmp(const struct object_id *oid1, const struct
> object_id *oid2)
> {
> - return hashcmp(oid1->hash, oid2->hash);
> + return memcmp(oid1->hash, oid2->hash, the_hash_algo->rawsz);
> }
>
Just curious,
Remove the hard-coded 20-based values and replace them with uses of
the_hash_algo.
Signed-off-by: brian m. carlson
---
tree-walk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tree-walk.c b/tree-walk.c
index 8f5090862b..c1f27086a9 100644
--- a/tree-walk.c
+++
Instead of using the GIT_SHA1_* constants, switch to using the_hash_algo
to convert object IDs to and from hex format.
Signed-off-by: brian m. carlson
---
hex.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hex.c b/hex.c
index 8df2d63728..10af1a29e8 100644
---
Signed-off-by: brian m. carlson
---
log-tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/log-tree.c b/log-tree.c
index d3a43e29cd..9655de8ad7 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -545,7 +545,7 @@ void show_log(struct rev_info *opt)
struct strbuf msgbuf =
Switch from using GIT_SHA1_HEXSZ to the_hash_algo to make the parsing of
the index information hash independent.
Signed-off-by: brian m. carlson
---
builtin/update-index.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/builtin/update-index.c
In order to ensure we write the correct amount, use the_hash_algo to
find the correct number of bytes for the current hash.
Signed-off-by: brian m. carlson
---
refs/files-backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs/files-backend.c
In order to be sure we have enough space to use with any hash algorithm,
use GIT_MAX_HEXSZ to allocate space.
Signed-off-by: brian m. carlson
---
strbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/strbuf.c b/strbuf.c
index b0716ac585..030556111d 100644
--- a/strbuf.c
Use GIT_MAX_HEXSZ instead of GIT_SHA1_HEXSZ for an allocation so that it
is sufficiently large. Switch a comparison to use the_hash_algo to
determine the length of a hex object ID.
Signed-off-by: brian m. carlson
---
builtin/merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2
Convert one use of 20 and several uses of GIT_SHA1_HEXSZ into references
to the_hash_algo.
Signed-off-by: brian m. carlson
---
sha1-file.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sha1-file.c b/sha1-file.c
index de4839e634..1f66b9594f 100644
--- a/sha1-file.c
100 bytes is not sufficient to ensure we can write a commit message
buffer when using a 32-byte hash algorithm. Increase the buffer size to
ensure we have sufficient space.
Signed-off-by: brian m. carlson
---
refs/files-backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Switch several hard-coded constants into expressions based either on
GIT_MAX_HEXSZ or the_hash_algo.
Signed-off-by: brian m. carlson
---
pretty.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pretty.c b/pretty.c
index 703fa6ff7b..b0e653ff25 100644
--- a/pretty.c
+++
Switch uses of GIT_SHA1_HEXSZ to use the_hash_algo instead.
Signed-off-by: brian m. carlson
---
builtin/merge.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 4a4c09496c..916c9f0569 100644
--- a/builtin/merge.c
+++
Signed-off-by: brian m. carlson
---
sha1-name.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/sha1-name.c b/sha1-name.c
index 60d9ef3c7e..ba6a5a689f 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -310,7 +310,7 @@ static int init_object_disambiguation(const char
Update the hashcpy and hashclr functions to use the_hash_algo, since
they are used in a variety of places to copy and manipulate buffers that
need to move data into or out of struct object_id. Update oidcmp so
that it is implemented on its own and similarly uses the_hash_algo.
Signed-off-by:
This is the fourteenth series of patches to switch to using struct
object_id and the_hash_algo. This series converts several core pieces
to use struct object_id, including the oid* and hex functions.
All of these patches have been tested with both SHA-1 and a 256-bit
hash.
brian m. carlson
Convert several uses of GIT_SHA1_HEXSZ into references to the_hash_algo.
Switch other uses into a use of parse_oid_hex and uses of its computed
pointer.
Signed-off-by: brian m. carlson
---
builtin/fmt-merge-msg.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff
Specify these constants in terms of the size of the hash algorithm
currently in use.
Signed-off-by: brian m. carlson
---
commit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index 0c3b75aeff..ff05d04570 100644
--- a/commit.c
+++ b/commit.c
@@
Signed-off-by: brian m. carlson
---
diff.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 639eb646b9..485ff6c264 100644
--- a/diff.c
+++ b/diff.c
@@ -3832,7 +3832,7 @@ static const char *diff_abbrev_oid(const struct object_id
*oid, int abbrev)
Switch from using get_oid_hex to parse_oid_hex to simplify pointer
operations and avoid the need for a hash-related constant.
Signed-off-by: brian m. carlson
---
builtin/update-index.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin/update-index.c
LGTM, thanks for the v2.
With --validate (which is the default), we warn about lines exceeding
998 characters due to the limits specified in RFC 5322. However, if
we're using a suitable transfer encoding (quoted-printable or base64),
we're guaranteed not to have lines exceeding 76 characters, so there's
no need to fail
The git send-email documentation specifies RFC 2821 (the SMTP RFC) as
providing line length limits, but the specification that restricts line
length to 998 octets is RFC 2822 (the email message format RFC). Since
RFC 2822 has been obsoleted by RFC 5322, update the text to refer to RFC
5322
git send-email, when invoked without a --transfer-encoding option, sends
8bit data without a MIME version or a transfer encoding. This has
several downsides.
First, unless the transfer encoding is specified, it defaults to 7bit,
meaning that non-ASCII data isn't allowed. Second, if lines longer
This series introduces an "auto" value for git send-email
--transfer-encoding that uses 8bit when possible (i.e. when lines are
998 octets or shorter) and quoted-printable otherwise; it then makes
this the default behavior. It also makes --validate aware of transfer
encoding so it doesn't
For most patches, using a transfer encoding of 8bit provides good
compatibility with most servers and makes it as easy as possible to view
patches. However, there are some patches for which 8bit is not a valid
encoding: RFC 5322 specifies that a message must not have lines
exceeding 998 octets.
Hi Paul,
On Sun, 8 Jul 2018, Paul Smith wrote:
> On Fri, 2018-07-06 at 09:18 -0400, Daniel Jacques wrote:
> > I forewent autoconf because I was concerned that the option was too
> > obscure and the configuration too nuanced to be worth adding via
> > flag, as RUNTIME_PREFIX requires some degree
Hi Pratik,
On Sun, 8 Jul 2018, Pratik Karki wrote:
> + strbuf_addf(_snippet,
> + ". git-rebase--common && . %s && %s",
> + backend, backend_func);
In my quick test (on top of `wip-rebase`), this line needed this change:
-- snip --
@@ -269,7 +279,8 @@ static
Hi Pratik,
On Sun, 8 Jul 2018, Pratik Karki wrote:
> diff --git a/checkout.c b/checkout.c
> index bdefc888ba..da68915fd7 100644
> --- a/checkout.c
> +++ b/checkout.c
> @@ -2,6 +2,11 @@
> #include "remote.h"
> #include "refspec.h"
> #include "checkout.h"
> +#include "unpack-trees.h"
>
From: "Eric Sunshine"
To: "Beat Bolli"
On Sun, Jul 8, 2018 at 10:44 AM Beat Bolli wrote:
The marco GIT_PATH_FUNC expands to a complete statement including the
s/marco/macro/
semicolon. Remove two extra trailing semicolons.
Signed-off-by: Beat Bolli
---
sequencer.c | 4 ++--
1 file
Hi Pratik,
On Sun, 8 Jul 2018, Pratik Karki wrote:
> As a GSoC project, I have been working on the builtin rebase.
>
> The motivation behind the rewrite of rebase i.e. from shell script to C
> are for following reasons:
>
> 1. Writing shell scripts and getting it to production is much faster
On Sun, Jul 08, 2018 at 09:41:11PM +0300, Daniel Harding wrote:
> Signed-off-by: Daniel Harding
I think maybe, as you suggested, a separate test for this would be
beneficial. It might be as simple as modifying 'script-from-scratch' by
doing "sed 's/#/>/'".
> diff --git
On Sun, Jul 8, 2018 at 10:44 AM Beat Bolli wrote:
> The marco GIT_PATH_FUNC expands to a complete statement including the
> semicolon. Remove two extra trailing semicolons.
>
> Signed-off-by: Beat Bolli
> ---
> sequencer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
While
On Fri, 2018-07-06 at 09:18 -0400, Daniel Jacques wrote:
> I forewent autoconf because I was concerned that the option was too
> obscure and the configuration too nuanced to be worth adding via
> flag, as RUNTIME_PREFIX requires some degree of path alignment and is
> fairly special-case. If you
Prefix the "Branch " comments in the todo list with the configured
comment character instead of hard-coding '#'.
Signed-off-by: Daniel Harding
---
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index 4034c0461..caf91af29 100644
---
I have core.commentChar set in my .gitconfig, and when I tried to run
git rebase -i -r, I received an error message like the following:
error: invalid line 3: # Branch
To fix this, I updated sequencer.c to use the configured commentChar
for the Branch comments. I also tweaked the tests in
Signed-off-by: Daniel Harding
---
t/t3430-rebase-merges.sh | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/t/t3430-rebase-merges.sh b/t/t3430-rebase-merges.sh
index 78f7c9958..ff474d033 100755
--- a/t/t3430-rebase-merges.sh
+++ b/t/t3430-rebase-merges.sh
@@ -56,12
> On Jul 8, 2018, at 8:30 PM, larsxschnei...@gmail.com wrote:
>
> From: Lars Schneider
>
> In 107642fe26 ("convert: add 'working-tree-encoding' attribute",
> 2018-04-15) we added an attribute which defines the working tree
> encoding of a file.
>
> Some platforms might spell the name of a
> On Jul 8, 2018, at 8:30 PM, larsxschnei...@gmail.com wrote:
>
> From: Lars Schneider
>
> Refactor conversion driver config parsing to ease the parsing of new
> configs in a subsequent patch.
>
> No functional change intended.
>
> Signed-off-by: Lars Schneider
> ---
> convert.c | 64
From: Lars Schneider
In 107642fe26 ("convert: add 'working-tree-encoding' attribute",
2018-04-15) we added an attribute which defines the working tree
encoding of a file.
Some platforms might spell the name of a certain encoding differently or
some users might want to use different encodings on
From: Lars Schneider
Refactor conversion driver config parsing to ease the parsing of new
configs in a subsequent patch.
No functional change intended.
Signed-off-by: Lars Schneider
---
convert.c | 64 +++
1 file changed, 32 insertions(+),
From: Lars Schneider
Hi,
this series adds Git config based alias support for
'working-tree-encoding' attributes that were introduced in 107642fe26
("convert: add 'working-tree-encoding' attribute", 2018-04-15).
The feature was suggested by Steve Groeger in [1].
The first patch is a refactoring
This patch gives life to the skeleton added in the previous patches:
With this change, we can perform a elementary rebase (without any
options).
It can be tested thusly by:
git -c rebase.usebuiltin=true rebase HEAD~2
The rebase backends (i.e. the shell script functions defined in
In the upcoming builtin rebase, we will have to start by detaching
the HEAD, just like shell script version does. Essentially, we have
to do the same thing as `git checkout -q ^0 --`, in pure C.
The aforementioned functionality was already present in `sequencer.c`
in `do_reset()` function. But
The functions present in `git-legacy-rebase.sh` are used by the rebase
backends as they are implemented as shell script functions in the
`git-rebase--` files.
To make the `builtin/rebase.c` work, we have to provide support via
a Unix shell script snippet that uses these functions and so, we
want
This commit imitates the strategy that was used to convert the
difftool to a builtin. We start by renaming the shell script
`git-rebase.sh` to `git-legacy-rebase.sh` and introduce a
`builtin/rebase.c` that simply executes the shell script version,
unless the config setting `rebase.useBuiltin` is
As a GSoC project, I have been working on the builtin rebase.
The motivation behind the rewrite of rebase i.e. from shell script to C
are for following reasons:
1. Writing shell scripts and getting it to production is much faster
than doing the equivalent in C but lacks in performance and
The "\e" escape is not defined in ISO C.
While on this line, add a missing space after the comma.
Signed-off-by: Beat Bolli
---
convert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/convert.c b/convert.c
index 64d0d30e08..edebb946f5 100644
--- a/convert.c
+++
ISO C forbids the conversion of void pointers to function pointers.
Introduce a context struct that encapsulates the function pointer.
Signed-off-by: Beat Bolli
---
string-list.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/string-list.c
Include iterator.h to define enum iterator_selection.
Signed-off-by: Beat Bolli
---
refs/refs-internal.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/refs/refs-internal.h b/refs/refs-internal.h
index dd834314bd..a78b5cb803 100644
--- a/refs/refs-internal.h
+++ b/refs/refs-internal.h
@@
In ISO C, char constants must be in the range -128..127. Change the BOM
constants to unsigned char to avoid overflow.
Signed-off-by: Beat Bolli
---
utf8.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/utf8.c b/utf8.c
index d55e20c641..833ce00617 100644
---
The marco GIT_PATH_FUNC expands to a complete statement including the
semicolon. Remove two extra trailing semicolons.
Signed-off-by: Beat Bolli
---
sequencer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 5354d4d51e..66e7073995 100644
Include protocol.h to define enum protocol_version.
Signed-off-by: Beat Bolli
---
connect.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/connect.h b/connect.h
index 0e69c6709c..c86f862f2f 100644
--- a/connect.h
+++ b/connect.h
@@ -1,6 +1,8 @@
#ifndef CONNECT_H
#define CONNECT_H
While developing 6aaded550 ("builtin/config: work around an unsized
array forward declaration", 2018-07-05), I have compiled Git with
CFLAGS="-std=c99 -pedantic".
This is an RFC patch series that fixes a few compiler warnings when
compiling with these options, always assuming that this is a
Dear Eric,
Thank you for the prompt response and the links.
Cheers, Josip
On 8/07/2018 19:08, Eric Sunshine wrote:
On Sun, Jul 8, 2018 at 4:23 AM josip zamboni
wrote:
I've noticed there is no Croatian version of Pro Git Book and I'd like
to produce it. If you agree, do let me know the
On Sun, Jul 8, 2018 at 4:23 AM josip zamboni
wrote:
> I've noticed there is no Croatian version of Pro Git Book and I'd like
> to produce it. If you agree, do let me know the contact details of
> person(s) I should be dealing with.
The Pro Git book is a separate project from Git itself. They
Dear all,
I've noticed there is no Croatian version of Pro Git Book and I'd like
to produce it. If you agree, do let me know the contact details of
person(s) I should be dealing with.
With kind regards,
Josip Zamboni
Castle Hill, NSW 2154, Australia
Phone: +614 03 234 333
61 matches
Mail list logo
