>From adfcfa0a334378a6242347efc0d614fa193610db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pawe=C5=82=20Wawruch?=
Date: Thu, 6 Mar 2014 00:05:00 +0100
Subject: [PATCH] branch.c:install_branch_config(): Simplify the long chain of
if statements. Threre was a long chain of if statements. The code can b
From: Duy Nguyen
Before cdab485 (upload-pack: delegate rev walking in shallow fetch to
pack-objects - 2013-08-16) upload-pack does not write to the source
repository. cdab485 starts to write $GIT_DIR/shallow_XX if it's a
shallow fetch, so the source repo must be writable.
git:// servers do n
On 03/05/2014 08:18 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Wed, Mar 05, 2014 at 10:49:24AM -0800, Junio C Hamano wrote:
>>
>>> ... the plan, at least in my mind, has always been exactly that: grafts
>>> were a nice little attempt but is broken---if you really wanted to
>>> muck wit
hashcpy() can keep the abstraction of "object name" behind it.
Use it instead of memcpy() with hard-coded 20-byte length when
moving object names between pieces of memory.
We can benefit from it, when we switch to another hash algorithm,
eg. MD5, by just fixing the hashcpy().
Leave ppc/sha1.c as i
On Thu, Mar 6, 2014 at 9:42 AM, Michael Haggerty wrote:
> On 03/05/2014 08:18 PM, Junio C Hamano wrote:
>> Jeff King writes:
>>
>>> On Wed, Mar 05, 2014 at 10:49:24AM -0800, Junio C Hamano wrote:
>>>
... the plan, at least in my mind, has always been exactly that: grafts
were a nice lit
On Tue, 2014-03-04 at 11:44 -0800, Junio C Hamano wrote:
> Krzesimir Nowak writes:
>
> > It might be possible (in "Gerrited" setups) to have local branches
> > outside refs/heads/, like for example in following fetch config:
> >
> > [remote "origin"]
> > url = ssh://u...@example.com/my-projec
On Wed, Mar 5, 2014 at 9:06 AM, Karthik Nayak wrote:
> Replaces all instances of starts_with() by skip_prefix(),
Use imperative mode: "Replace all..."
> which can not only be used to check presence of a prefix,
> but also used further on as it returns the string after the prefix,
> if the prefix
On Sat, Mar 1, 2014 at 7:12 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/checkout.c | 49 +++--
> 1 file changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index
On Thu, Mar 6, 2014 at 9:55 AM, Robert Dailey wrote:
> What I'd like to do is somehow hunt down the largest commit (*not*
> blob) in the entire history of the repository to hopefully find out
> where huge directories have been checked in.
Another try
git rev-list --all|while read i;do echo -n "$
Atten:
Simply contact Diplomat Mrs Cherina Garcia with your full delivery address And
your nearest airport to land, on this information below so that she can
deliver the Package to you; Name: Mrs Cherina Garcia
Email:(mrs.charina.gar...@barid.com)
Regards,
Mr, John Roland
--
To unsubscribe fro
Add (failing) test: with commit changing the environment to let hooks
now that no editor will be used (by setting GIT_EDITOR to ":"), the
"edit hunk" functionality does not work (no editor is launched and the
whole hunk is committed).
Signed-off-by: Benoit Pierre
---
t/t7513-commit_-p_-m_hunk_ed
This patch fixes the fact that hunk editing with 'commit -p -m' does not work:
GIT_EDITOR is set to ':' to indicate to hooks that no editor will be launched,
which result in the 'hunk edit' option not launching the editor (and selecting
the whole hunk).
The fix consists in deferring the GIT_EDITOR
Signed-off-by: Benoit Pierre
---
t/t7505-prepare-commit-msg-hook.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7505-prepare-commit-msg-hook.sh
b/t/t7505-prepare-commit-msg-hook.sh
index ae7b2db..604c06e 100755
--- a/t/t7505-prepare-commit-msg-hook.sh
+++ b/t/t7505-pre
Don't set GIT_EDITOR to ":" when calling prepare-commit-msg hook if the
editor is going to be called (e.g. with "merge -e").
Signed-off-by: Benoit Pierre
---
builtin/merge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index d2a1bfe..da7ca
Signed-off-by: Benoit Pierre
---
t/t7505-prepare-commit-msg-hook.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7505-prepare-commit-msg-hook.sh
b/t/t7505-prepare-commit-msg-hook.sh
index 604c06e..1be6cec 100755
--- a/t/t7505-prepare-commit-msg-hook.sh
+++ b/t/t7505
- update 'no editor' hook test and add 'editor' hook test
- reset tree at the beginning of failing hook tests to avoid failures
due to an unclean tree after running a previous test
Signed-off-by: Benoit Pierre
---
t/t7505-prepare-commit-msg-hook.sh | 17 -
1 file changed, 16 in
Don't change git environment: move the GIT_EDITOR=":" override to the
hook command subprocess, like it's already done for GIT_INDEX_FILE.
Signed-off-by: Benoit Pierre
---
builtin/commit.c | 35 ---
builtin/merge.c | 4 ++--
comm
On Wed, Mar 05, 2014 at 08:55:30PM -0600, Robert Dailey wrote:
> What I'd like to do is somehow hunt down the largest commit (*not*
> blob) in the entire history of the repository to hopefully find out
> where huge directories have been checked in.
>
> I can't do a search for largest file (which
On Thu, Mar 06, 2014 at 09:42:46AM +0100, Michael Haggerty wrote:
> Replace objects are better than grafts in *almost* every dimension. The
> exception is that it is dead simple to create grafts, whereas I always
> have to break open the man pages to remember how to create a replace
> object that
On 03/06/2014 04:56 PM, Jeff King wrote:
> On Thu, Mar 06, 2014 at 09:42:46AM +0100, Michael Haggerty wrote:
>
>> Replace objects are better than grafts in *almost* every dimension. The
>> exception is that it is dead simple to create grafts, whereas I always
>> have to break open the man pages t
Replace all instances of starts_with() by skip_prefix(),
which can not only be used to check presence of a prefix,
but also used further on as it returns the string after the prefix,
if the prefix is present. And also manages to do, what the current
code does in two steps.
Signed-off-by: Karthik N
I have a shell script that trims old history on a cronjob. This is for
a repo that is used to track reports that have limited "life" (like
logs). Old history is trimmed with grafts pointing to an empty "root"
commit.
Right now, info/graft grows unbound. I am looking for a way to trim
unreachable g
On Thu, Mar 06, 2014 at 05:41:27PM +0100, Michael Haggerty wrote:
> > We can wrap that in "git replace --convert-grafts", but I do not think
> > grafts are so common that there would be a big demand for it.
>
> It's probably easier to wrap it than to explain to Windows users what
> they have to d
The git-replace command has three modes: listing, deleting,
and replacing. The first two are selected explicitly. If
none is selected, we fallback to listing when there are no
arguments, and replacing otherwise.
Let's figure out up front which operation we are going to
do, before getting into the
By using OPT_CMDMODE, the mutual exclusion between modes is
taken care of for us. It also makes it easy for us to
maintain a single variable with the mode, which makes its
intent more clear. We can use a single switch() to make sure
we have covered all of the modes.
This ends up breaking even in c
As we add new options that operate on objects before
replacing them, we'll want to be able to feed raw sha1s
straight into replace_object. Split replace_object into the
object-resolution part and the actual replacement.
Signed-off-by: Jeff King
---
builtin/replace.c | 26 ++--
This allows you to run:
git replace --edit SHA1
to get dumped in an editor with the contents of the object
for SHA1. The result is then read back in and used as a
"replace" object for SHA1. The writing/reading is
type-aware, so you get to edit "ls-tree" output rather than
the binary tree form
Conley Owens writes:
> On Fri, Feb 28, 2014 at 3:26 PM, Conley Owens wrote:
>> $ git --version # This is just the git from MacPorts
>> git version 1.8.5.5
>> $ sw_vers
>> ProductName:Mac OS X
>> ProductVersion: 10.8.5
>> BuildVersion: 12F45
>
> OK, I've tried using my own build from maste
Nguyễn Thái Ngọc Duy writes:
> From: Duy Nguyen
>
> Before cdab485 (upload-pack: delegate rev walking in shallow fetch to
> pack-objects - 2013-08-16) upload-pack does not write to the source
> repository. cdab485 starts to write $GIT_DIR/shallow_XX if it's a
> shallow fetch, so the source
On Thu, Mar 06, 2014 at 07:35:19PM +0100, Christian Couder wrote:
> > + if (!cmdmode)
> > + cmdmode = argc ? MODE_REPLACE : MODE_DELETE;
>
> Shouldn't it be MODE_LIST instead of MODE_DELETE?
Argh, yes, thank you for catching. My original iteration used chars like
'd' and 'l'
Jeff King writes:
> I also noticed that the diff engine does not play well with replacements
> of blobs. When we are diffing the trees, we see that the sha1 for path
> "foo" is the same on either side, and do not look further, even though
> feeding those sha1s to builtin_diff would fetch the repl
On Thu, Mar 06, 2014 at 11:00:08AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I also noticed that the diff engine does not play well with replacements
> > of blobs. When we are diffing the trees, we see that the sha1 for path
> > "foo" is the same on either side, and do not look furt
On Tue, Mar 4, 2014 at 4:56 AM, Thomas Ferris Nicolaisen
wrote:
> On Mon, Mar 3, 2014 at 7:38 PM, Robert Dailey
> wrote:
>>
>> Is it safe to do this while still using git svn fetch? Will it
>> properly continue to convert SVN commits on top of my rewritten
>> history? If not, what changes can I
Martin Langhoff writes:
> I have a shell script that trims old history on a cronjob. This is for
> a repo that is used to track reports that have limited "life" (like
> logs). Old history is trimmed with grafts pointing to an empty "root"
> commit.
>
> Right now, info/graft grows unbound. I am lo
Michael Haggerty writes:
> I just wrote up the idea that fell out of the discussion [1] about the
> other configuration features that I proposed. As far as I am concerned,
> it can be merged as soon as somebody volunteers as a co-mentor. The
> idea is embodied in a pull request against the git.
On Thu, Mar 6, 2014 at 2:17 PM, Andreas Schwab wrote:
> Does git fsck --unreachable --no-reflogs help?
Well, my script, called regularly, does:
- adds grafts
- git repack -AFfd (which unpacks unreachable objects)
- git prune --expire now
hmm, I guess could prune the grafts using git fsc
Sun He writes:
> hashcpy() can keep the abstraction of "object name" behind it.
Do we really want to change the phrasing you took the above from to
say "*can* keep"?
Providing the "object name" abstraction is the whole point of the
function, so of course it can keep it, but that goes without
sa
Am 06.03.2014 01:15, schrieb Henri GEIST:
> Le mercredi 05 mars 2014 à 19:00 +0100, Jens Lehmann a écrit :
>> Am 05.03.2014 00:01, schrieb Henri GEIST:
>> - Wouldn't it be easier to pass the '--recurse-submodules"
>> option to the "git clone" call for the superproject instead
>> of adding the _
We already have 147972b1 (commit.c: use skip_prefix() instead of
starts_with(), 2014-03-04) that covers the record_author_date() and
parse_gpg_output(), don't we?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo
Karthik Nayak writes:
> @@ -1098,6 +1099,7 @@ int parse_signed_commit(const unsigned char *sha1,
> char *buffer = read_sha1_file(sha1, &type, &size);
> int in_signature, saw_signature = -1;
> char *line, *tail;
> + const char *gpg_sig;
>
> if (!buffer || type != OBJ_
On Thu, Mar 06, 2014 at 11:24:18AM -0800, Junio C Hamano wrote:
> > * Add new API calls that allow the cache to be inquired easily and
> > efficiently. Rewrite other functions like `git_config_int()` to be
> > cache-aware.
>
> Are you sure about the second sentence of this item is what you
>
Am 06.03.2014 02:25, schrieb Henri GEIST:
> Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :
>> Am 03.03.2014 21:34, schrieb Henri GEIST:
>>> Le lundi 03 mars 2014 à 17:45 +, Jens Lehmann a écrit :
Am 03.03.2014 14:47, schrieb Henri GEIST:
> This new option prevent git su
When looking at a merge, "git blame" inspects the blob object names
of all parents and if one of them exactly match the merge result,
pass the entire blame down to that parent. This is very much in
line with the history simplification done with "git log" when
traversing a history with merges.
On
Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :
> Am 06.03.2014 02:25, schrieb Henri GEIST:
> > Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :
> >> Am 03.03.2014 21:34, schrieb Henri GEIST:
> >>> Le lundi 03 mars 2014 à 17:45 +, Jens Lehmann a écrit :
> Am 03.03
Junio C Hamano writes:
> When looking at a merge, "git blame" inspects the blob object names
> of all parents and if one of them exactly match the merge result,
> pass the entire blame down to that parent. This is very much in
> line with the history simplification done with "git log" when
> tra
On Thu, Mar 06, 2014 at 12:17:34PM -0500, Martin Langhoff wrote:
> I have a shell script that trims old history on a cronjob. This is for
> a repo that is used to track reports that have limited "life" (like
> logs). Old history is trimmed with grafts pointing to an empty "root"
> commit.
>
> Rig
David Kastrup writes:
> Junio C Hamano writes:
>
>> When looking at a merge, "git blame" inspects the blob object names
>> of all parents and if one of them exactly match the merge result,
>> pass the entire blame down to that parent. This is very much in
>> line with the history simplification
Am 06.03.2014 21:15, schrieb Henri GEIST:
> Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :
>> Am 06.03.2014 02:25, schrieb Henri GEIST:
>>> Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :
Am 03.03.2014 21:34, schrieb Henri GEIST:
> - I use an other patch which
Rohit Mani writes:
> Avoid scanning strings twice, once with strchr() and then with
> strlen(), by using strchrnul(). Update the conditional expressions
> involving the return value of strchrnul() with a check for '\0'.
>
> Signed-off-by: Rohit Mani
> ---
Nicely done. I am not sure if you need
On Wed, Mar 05, 2014 at 04:31:55PM +0900, Brian Gesiak wrote:
> No test asserts that "git branch -u refs/heads/my-branch my-branch"
> emits a warning. Add a test that does so.
>
> Signed-off-by: Brian Gesiak
Thanks, this looks good. Two minor points that may or may not be worth
addressing:
> +
Benoit Pierre writes:
> This patch fixes the fact that hunk editing with 'commit -p -m' does not work:
> GIT_EDITOR is set to ':' to indicate to hooks that no editor will be launched,
> which result in the 'hunk edit' option not launching the editor (and selecting
> the whole hunk).
>
> The fix c
On Thu, Mar 06, 2014 at 10:24:49AM -0800, Junio C Hamano wrote:
> > OK, I've tried using my own build from master, and I still get the same
> > results.
> >
> > I've done a little more investigation and discovered it always hangs at:
> > `atexit(notify_parent);` in `run-command.c:start_command`
>
I have no clue why git diff --cached isn't used instead of git
diff-index. I was wondering about it, but I decided I don't know
enough about git and there are probably valid reasons for doing it
this way. Though, replacing it with with git diff --cached seems to
have the exact same behaviour, as fa
Benoit Pierre writes:
> +int run_commit_hook(int editor_is_used, const char *index_file, const char
> *name, ...)
> +{
> + const char *hook_env[3] = { NULL };
> + char index[PATH_MAX];
> + va_list args;
> + int ret;
> +
> + snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s",
Benoit Pierre writes:
> Signed-off-by: Benoit Pierre
> ---
Please have these preparatory fix-ups (i.e. the changes that would
be immediately useful even if it turns out that the main body of the
series were not ready for inclusion) early in the series, not late
as 5th patch of a 6 patch series.
On Wed, Mar 05, 2014 at 08:58:26AM +0100, Johannes Sixt wrote:
> Here is a patch that I'm carrying around since... a while.
> What do you think?
>
> The pattern I chose also catches variable definition, not just
> functions. That is what I need, but it hurts grep --function-context
> That's the r
Benoit Pierre writes:
> Signed-off-by: Benoit Pierre
> ---
> t/t7505-prepare-commit-msg-hook.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t7505-prepare-commit-msg-hook.sh
> b/t/t7505-prepare-commit-msg-hook.sh
> index 604c06e..1be6cec 100755
> --- a/t/t7505
On 03/06/2014 08:24 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I just wrote up the idea that fell out of the discussion [1] about the
>> other configuration features that I proposed. As far as I am concerned,
>> it can be merged as soon as somebody volunteers as a co-mentor. The
Junio C Hamano writes:
> Name it run_hook_le() (name modelled after execle()), and call it in
> your change where you add new calls to this function, and add a thin
> wrapper run_hook() that preserves the traditional "We can pass only
> the index-file" for new callers we do not even know about on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I've noticed some behavior of git that might lead to some security
issues if the user is not aware of this.
Assume we have an evil user on a system, let's call him eve. He
prepares a repository where he allows other user to push changes to.
If
Jeff King writes:
> On Wed, Mar 05, 2014 at 04:31:55PM +0900, Brian Gesiak wrote:
>
>> No test asserts that "git branch -u refs/heads/my-branch my-branch"
>> emits a warning. Add a test that does so.
>>
>> Signed-off-by: Brian Gesiak
>
> Thanks, this looks good. Two minor points that may or may
On Thu, Mar 06, 2014 at 08:35:48PM +0100, Jens Lehmann wrote:
> Am 06.03.2014 01:15, schrieb Henri GEIST:
> > Le mercredi 05 mars 2014 à 19:00 +0100, Jens Lehmann a écrit :
> >> Am 05.03.2014 00:01, schrieb Henri GEIST:
> >> - Wouldn't it be easier to pass the '--recurse-submodules"
> >> option t
On Thu, Mar 6, 2014 at 9:50 AM, Benoit Pierre wrote:
> Add (failing) test: with commit changing the environment to let hooks
> now that no editor will be used (by setting GIT_EDITOR to ":"), the
> "edit hunk" functionality does not work (no editor is launched and the
> whole hunk is committed).
>
On Thu, Mar 6, 2014 at 9:50 AM, Benoit Pierre wrote:
> - update 'no editor' hook test and add 'editor' hook test
> - reset tree at the beginning of failing hook tests to avoid failures
> due to an unclean tree after running a previous test
>
> Signed-off-by: Benoit Pierre
> ---
> t/t7505-prepa
Le jeudi 06 mars 2014 à 21:51 +0100, Jens Lehmann a écrit :
> Am 06.03.2014 21:15, schrieb Henri GEIST:
> > Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :
> >> Am 06.03.2014 02:25, schrieb Henri GEIST:
> >>> Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :
> Am 03.03
From: "Jeff King"
On Thu, Mar 06, 2014 at 05:41:27PM +0100, Michael Haggerty wrote:
> We can wrap that in "git replace --convert-grafts", but I do not
> think
> grafts are so common that there would be a big demand for it.
It's probably easier to wrap it than to explain to Windows users what
Back in
http://git.661346.n2.nabble.com/PATCH-0-2-Make-git-gc-more-robust-with-regard-to-grafts-td3310281.html
we got gc/repack to be safer for users who might be shooting
themselves in the foot.
Would a patch be welcome to add --discard-grafted-objects ? or
--keep-real-parents=idontthinkso ?
ch
Eric Sunshine writes:
>> +test_expect_failure 'edit hunk "commit -p -m message"' '
>> + echo e | env GIT_EDITOR="sed s/+line3\$/+line2/ -i" git commit -p -m
>> commit2 file &&
>> + git diff HEAD^ HEAD >diff &&
>> + test_cmp expected diff
>> +'
>
> If you ever add more tests, is
On Thu, Mar 6, 2014 at 1:16 PM, Jeff King wrote:
> On Thu, Mar 06, 2014 at 10:24:49AM -0800, Junio C Hamano wrote:
>
>> > OK, I've tried using my own build from master, and I still get the same
>> > results.
>> >
>> > I've done a little more investigation and discovered it always hangs at:
>> > `
On Fri, Mar 7, 2014 at 1:37 AM, Junio C Hamano wrote:
> I like what I see in this patch, but I wonder if we can essentially
> revert that "temporary shallow file" patch and replace it with the
> same (or a similar) mechanism uniformly?
Using --shallow-file is uniform.The only downside is temporar
In a bourne shell script, "VAR=VAL command" is sufficient to run
'command' with environment variable VAR set to value VAL without
affecting the environment of the shell itself; there is no reason to
say "env VAR=VAL command".
Signed-off-by: Junio C Hamano
---
* Just something I noticed while re
Martin Langhoff writes:
> Back in
> http://git.661346.n2.nabble.com/PATCH-0-2-Make-git-gc-more-robust-with-regard-to-grafts-td3310281.html
> we got gc/repack to be safer for users who might be shooting
> themselves in the foot.
>
> Would a patch be welcome to add --discard-grafted-objects ? or
>
On 03/07/2014 12:01 AM, Philip Oakley wrote:
> From: "Jeff King"
>> On Thu, Mar 06, 2014 at 05:41:27PM +0100, Michael Haggerty wrote:
>>
>>> > We can wrap that in "git replace --convert-grafts", but I do not >
>>> think
>>> > grafts are so common that there would be a big demand for it.
>>>
>>> It
On Thu, Mar 6, 2014 at 6:26 PM, Junio C Hamano wrote:
> Given that we in general frown upon long-term use of grafts (or
> "replace" for that matter), I am not sure if we want to go in that
> direction.
>
> Just a knee-jerk reaction, though.
Fair enough.
If I state my actual goals -- discarding o
Michael Haggerty writes:
> I didn't mean to insult all Windows users in general. I was only
> referring to the fact that since the default Windows command line is not
> a POSIX shell, even an experienced Windows user might have trouble
> figuring out how to execute a shell loop. Putting this fu
From: "Michael Haggerty"
On 03/07/2014 12:01 AM, Philip Oakley wrote:
From: "Jeff King"
On Thu, Mar 06, 2014 at 05:41:27PM +0100, Michael Haggerty wrote:
> We can wrap that in "git replace --convert-grafts", but I do not
> >
think
> grafts are so common that there would be a big demand fo
Junio C Hamano writes:
> Benoit Pierre writes:
>
>> Signed-off-by: Benoit Pierre
>> ---
>> t/t7505-prepare-commit-msg-hook.sh | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/t/t7505-prepare-commit-msg-hook.sh
>> b/t/t7505-prepare-commit-msg-hook.sh
>> index 604
On Fri, Mar 7, 2014 at 6:36 AM, Martin Langhoff
wrote:
> On Thu, Mar 6, 2014 at 6:26 PM, Junio C Hamano wrote:
>> Given that we in general frown upon long-term use of grafts (or
>> "replace" for that matter), I am not sure if we want to go in that
>> direction.
>>
>> Just a knee-jerk reaction, th
Because "VAR=VAL command" is sufficient to run 'command' with
environment variable VAR set to value VAL without affecting the
environment of the shell itself, but we cannot do the same with a
shell function (most notably, "test_must_fail"), we have subshell
invocations with multiple lines like this
On Thu, Mar 6, 2014 at 3:49 PM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
> index 3ae9092..a980574 100755
> --- a/t/t5537-fetch-shallow.sh
> +++ b/t/t5537-fetch-shallow.sh
> @@ -173,4 +173,17 @@ EOF
> )
> '
>
> +test_expect_success POSI
1dca155fe3fa (log: handle integer overflow in timestamps, 2014-02-24)
assigns the result of strtol() to an 'int' and then checks it against
LONG_MIN and LONG_MAX, indicating underflow or overflow, even though
'int' may not be large enough to represent those values.
On Mac, the compiler complains:
Currently in order to avoid --[no]-xxx form we have to resort to
declare full struct option. It'd be nice to have a set of OPT_* macros
with PARSE_OPT_NONEG set. Find and update all "struct option []"
declarations with the new macros (including ones that should never
accept --no- form, but do anywa
On Thu, Mar 6, 2014 at 12:51 PM, Jeff King wrote:
> This allows you to run:
>
> git replace --edit SHA1
>
> to get dumped in an editor with the contents of the object
> for SHA1. The result is then read back in and used as a
> "replace" object for SHA1. The writing/reading is
> type-aware, so
We invented hashcpy() to keep the abstraction of "object
name" behind it. Use it instead of calling memcpy() with
hard-coded 20-byte length when moving object names between
pieces of memory.
Leave ppc/sha1.c as it is, because the function is about the
SHA-1 hash algorithm whose output is and will
On Mon, Mar 3, 2014 at 7:15 AM, Duy Nguyen wrote:
> On Mon, Mar 3, 2014 at 7:02 AM, Eric Sunshine wrote:
>> On Sat, Mar 1, 2014 at 7:12 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> In the previous patch, git_snpath() is modified to allocate a new
>>> strbuf buffer because vsnpath() needs that. But th
On Fri, Mar 7, 2014 at 12:03 AM, Duy Nguyen wrote:
> On Mon, Mar 3, 2014 at 7:15 AM, Duy Nguyen wrote:
>> On Mon, Mar 3, 2014 at 7:02 AM, Eric Sunshine
>> wrote:
>>> On Sat, Mar 1, 2014 at 7:12 AM, Nguyễn Thái Ngọc Duy
>>> wrote:
In the previous patch, git_snpath() is modified to allocat
On Wed, Mar 5, 2014 at 11:52 PM, Junio C Hamano wrote:
>
> This round is marked as the sixth, but I still see quite a many
> style issues, which I expect not to see from long timers without
> being told. Somewhat disappointing...
Yeah, I don't know why, but these days I find it very hard to revi
This patch implements reading the configuration
to get trailer information, and then processing
it and storing it in a doubly linked list.
The config information is stored in the list
whose first item is pointed to by:
static struct trailer_item *first_conf_item;
Signed-off-by: Christian Couder
This patch series implements a new command:
git interpret-trailers
and an infrastructure to process trailers that can be reused,
for example in "commit.c".
1) Rationale:
This command should help with RFC 822 style headers, called
"trailers", that are found at the end of commit messages.
Signed-off-by: Christian Couder
---
t/t7513-interpret-trailers.sh | 214 ++
1 file changed, 214 insertions(+)
create mode 100755 t/t7513-interpret-trailers.sh
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
new file mode 100755
Read trailers from stdin, parse them and put the result into a doubly linked
list.
Signed-off-by: Christian Couder
---
trailer.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/trailer.c b/trailer.c
index 43cbf10..910eddb 10064
Signed-off-by: Christian Couder
---
t/t7513-interpret-trailers.sh | 47 +++
1 file changed, 47 insertions(+)
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
index 1c5ed81..07e1b60 100755
--- a/t/t7513-interpret-trailers.sh
+++ b/
This patch adds the process_trailers() function that
calls all the previously added processing functions
and then prints the results on the standard output.
Signed-off-by: Christian Couder
---
trailer.c | 49 +
trailer.h | 6 ++
2 files change
Let the user specify a command that will give on its standard output
the value to use for the specified trailer.
Signed-off-by: Christian Couder
---
trailer.c | 63 +++
1 file changed, 63 insertions(+)
diff --git a/trailer.c b/trailer.
Parse the trailer command line arguments and put
the result into an arg_tok doubly linked list.
Signed-off-by: Christian Couder
---
trailer.c | 97 +++
1 file changed, 97 insertions(+)
diff --git a/trailer.c b/trailer.c
index 7a6d35d..
Signed-off-by: Christian Couder
---
Documentation/git-interpret-trailers.txt | 123 +++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/git-interpret-trailers.txt
diff --git a/Documentation/git-interpret-trailers.txt
b/Documentation/git-interpret-
Implement the logic to process trailers from stdin and arguments.
At the beginning trailers from stdin are in their own in_tok
doubly linked list, and trailers from arguments are in their own
arg_tok doubly linked list.
The lists are traversed and when an arg_tok should be "applied",
it is remove
We will use a doubly linked list to store all information
about trailers and their configuration.
This way we can easily remove or add trailers to or from
trailer lists while traversing the lists in either direction.
Signed-off-by: Christian Couder
---
Makefile | 1 +
trailer.c | 49 +
This patch adds the "git interpret-trailers" command.
This command uses the previously added process_trailers()
function in trailer.c.
Signed-off-by: Christian Couder
---
.gitignore | 1 +
Makefile | 1 +
builtin.h| 1 +
builtin/interp
On Sat, Mar 1, 2014 at 7:13 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/config.txt | 6 ++
> builtin/gc.c | 17 +
> 2 files changed, 23 insertions(+)
>
> diff --git a/Documentation/config.txt b/Documentation/config.
1 - 100 of 105 matches
Mail list logo
