On Wed, Jun 29, 2016 at 09:02:37AM +0200, Johannes Schindelin wrote:
> It is the most convenient way to determine which tests failed after
> running the entire test suite, in parallel, to look for left-over "trash
> directory.t*" subdirectories in the t/ subdirectory.
As Junio noted, this doesn't
On Tue, Jun 28, 2016 at 01:40:08PM +0200, Matthieu Moy wrote:
> This should address all comments from Peff.
Thanks. The review is mind-numbing enough that I didn't do a complete
read-through again, but just spot-checked a few places. This version
looks good to me.
-Peff
--
To unsubscribe from th
On Wed, Jun 29, 2016 at 01:47:31PM +0200, Johannes Schindelin wrote:
> On Tue, 28 Jun 2016, Junio C Hamano wrote:
>
> > * jk/ansi-color (2016-06-23) 7 commits
> > (merged to 'next' on 2016-06-28 at 354989c)
> > + color: support strike-through attribute
> > + color: support "italic" attribute
On Wed, Jun 29, 2016 at 12:48:33PM +0100, Laszlo Papp wrote:
> Old releases are maintained with important bug fixes or even new features
> in our case. It sometimes means that we need to cherry-pick commits across
> branches, like from master to a specific release branch.
>
> Cherry-picking chang
On Wed, 29 Jun 2016 at 18:40:16, Junio C Hamano wrote:
> Lukas, can you see what is in 'pu' after I push out today's
> integration result in several hours and tell us if you like the
> result of the SQUASH??? change?
Looks good to me. Thank you both for working on this. Note that you
should amend
Hi everyone,
I've found one case when this bug happens.
1. Create a commit
2. Amend it
3. Create several new commits
All the new commits have the same "Author" timestamp until the git gui
is restarted.
Can anyone reproduce this?
Best wishes,
Andrei Faber
On 29/06/2016 18:45, Johannes Sch
Am 29.06.2016 um 13:36 schrieb Johannes Schindelin:
@@ -955,9 +955,8 @@ static struct merge_file_info merge_file_1(struct
merge_options *o,
if (!sha_eq(a->sha1, b->sha1))
result.clean = 0;
- } else {
- d
Signed-off-by: Ramsay Jones
---
Hi Christian,
If you need to re-roll your 'cc/apply-am' branch, could you please
squash this into the relevant patch. Commit 95a3b0ba ("apply: move
libified code from builtin/apply.c to apply.{c,h}", 22-04-2016)
removed this '#include "builtin.h"' line, which cau
This implements everything that is required on the client side to make use
of push options from the porcelain push command.
Signed-off-by: Stefan Beller
---
Documentation/git-push.txt | 8 +++-
builtin/push.c | 16 +---
send-pack.c| 29 +++
The environment variable GIT_PUSH_OPTION_FILE is set to the push options
separated by new line.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
The rationale for keeping the actual options inside a file instead of
putting them directly into an e
Allow a user to pass information along a push to the pre/post-receive hook
on the remote.
When using a remote that is more than just a plain Git host (e.g. Gerrit,
Git{hub/lab}, etc) this may become more obvious: The (server backend specific)
push options can instruct the server to:
* open a pull
The functions `mk_repo_pair` as well as `test_refs` are borrowed from
t5543-atomic-push, with additional hooks installed.
Signed-off-by: Stefan Beller
---
t/t5544-push-options.sh | 85 +
1 file changed, 85 insertions(+)
create mode 100755 t/t5544-
The pre/post receive hook may be interested in more information from the
user. This information can be transmitted when both client and server
support the "push-options" capability, which when used is a phase directly
after update commands ended by a flush pkt.
Similar to the atomic option, the se
On 30/06/16 00:22, Junio C Hamano wrote:
[snip]
>
> * mh/ref-store (2016-06-20) 38 commits
> - refs: implement iteration over only per-worktree refs
> - refs: make lock generic
> - refs: add method to rename refs
> - refs: add methods to init refs db
> - refs: make delete_refs() virtual
>
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The first few batches for this cyc
Johannes Schindelin writes:
> When trying to match a pattern in the commit subject, simply skip leading
> blank lines in the commit message. This is consistent with the
> pretty-printing machinery: it silently ignores leading blank lines in the
> commit object's body.
>
> Signed-off-by: Johannes
On Wed, Jun 29, 2016 at 03:11:39PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes, though generation numbers can help with more questions (e.g., "what
> > is the merge base").
>
> Hmm, how? I have two commits, with generation number 38 and 47,
> respectively. What generation numbe
On 29.06.2016 22:39, Junio C Hamano wrote:
Stefan Beller writes:
On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano wrote:
On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
wrote:
This is no RFE but rather recurring thoughts whenever I'm working with
commit graphs: a topological index attribut
Jeff King writes:
> Yes, though generation numbers can help with more questions (e.g., "what
> is the merge base").
Hmm, how? I have two commits, with generation number 38 and 47,
respectively. What generation number does the commit that is the
merge base of these two commits?
I know we can s
Johannes Schindelin writes:
> Consistent with the pretty-printing machinery, we skip leading blank
> lines (if any) of existing commit messages.
>
> While Git itself only produces commit objects with a single empty line
> between commit header and commit message, it is legal to have more than
> o
Johannes Schindelin writes:
> Just like we already taught the find_commit_subject() function (to make
> it consistent with the code in pretty.c), we now simply skip leading
> blank lines of the commit message.
>
> Signed-off-by: Johannes Schindelin
> ---
> sequencer.c | 6 ++
> 1 file chang
On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
> > So this is the ideal case for generation numbers (the worst cases are
> > when the things you are looking for are in branchy, close history where
> > the generation numbers don't tell you much; but in such cases the
> > walking is
W dniu 2016-06-29 o 22:56, Jeff King pisze:
> On Wed, Jun 29, 2016 at 01:39:17PM -0700, Junio C Hamano wrote:
>
>>> Would it make sense to refuse creating commits that have a commit date
>>> prior to its parents commit date (except when the user gives a
>>> `--dammit-I-know-I-break-a-wildy-used-he
On Wed, Jun 29, 2016 at 02:37:17PM -0700, Stefan Beller wrote:
> On Wed, Jun 29, 2016 at 1:54 PM, Stefan Beller wrote:
> > Chances are that the 10 years of history may be correct time wise as long
> > as people don't introduce a bad date malevolently.
> >
>
> To answer my own speculation:
> Even
On Wed, Jun 29, 2016 at 1:54 PM, Stefan Beller wrote:
> Chances are that the 10 years of history may be correct time wise as long
> as people don't introduce a bad date malevolently.
>
To answer my own speculation:
Even git.git violates the timing property, so there is no hope to find
many projec
Jakub Narębski writes:
> But I think it is not the best place to keep this documentation.
All true. In case it was not obvious, I didn't mean to say "Here
you find the information, shut up." It was "here is a pointer if
you didn't find it, so that you can use it as a starting point to
make a b
Johannes Schindelin writes:
> - cp.git_cmd = 1;
> + init_merge_options(&o);
> +
> + o.branch1 = "HEAD";
> + his_tree_name = xstrfmt("%.*s", linelen(state->msg), state->msg);
> + o.branch2 = his_tree_name;
>
> - argv_array_pushf(&cp.env_array, "GITHEAD_%s=%.*s",
> -
W dniu 2016-06-29 o 21:51, Junio C Hamano pisze:
> On Wed, Jun 29, 2016 at 12:47 PM, Jakub Narębski wrote:
>> I have noticed that the magic pathspec ":/" is described only in RelNotes
>> for revision 1.7.6:
>> |I think the reason might be that there was no good place to put that
>> information in.
Johannes Schindelin writes:
> @@ -743,6 +741,8 @@ static int update_file_flags(struct merge_options *o,
> int update_cache,
> int update_wd)
> ...
> + ret = error_errno(_("do not know what to do with %06o
> %s '%s'"),
>
Johannes Schindelin writes:
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 6ab7dfc..bb075e3 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -266,8 +266,10 @@ struct tree *write_tree_from_memory(struct merge_options
> *o)
> active_cache_tree = cache_tre
On Wed, Jun 29, 2016 at 1:39 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano wrote:
>>> On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
>>> wrote:
This is no RFE but rather recurring thoughts whenever I'm working with
commit grap
W dniu 2016-06-29 o 20:59, Junio C Hamano pisze:
> On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
> wrote:
>
>> This is no RFE but rather recurring thoughts whenever I'm working with
>> commit graphs: a topological index attribute for commit objects would be
>> incredible useful. By "topological
On Wed, Jun 29, 2016 at 01:39:17PM -0700, Junio C Hamano wrote:
> > Would it make sense to refuse creating commits that have a commit date
> > prior to its parents commit date (except when the user gives a
> > `--dammit-I-know-I-break-a-wildy-used-heuristic`)?
>
> I think that has also been discu
Johannes Schindelin writes:
> The vast majority of error messages in Git's source code which report a
> bug use the convention to prefix the message with "BUG:".
Good thing to do.
But if we were to review and apply a 200+ line patch, I wonder if we
want to go one step further to allow us to wri
Stefan Beller writes:
> On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano wrote:
>> On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
>> wrote:
>>> This is no RFE but rather recurring thoughts whenever I'm working with
>>> commit graphs: a topological index attribute for commit objects would be
>>
On Wed, Jun 29, 2016 at 1:40 PM, Stefan Beller wrote:
>> + merge_head = lookup_commit_reference(merge_heads.sha1[0]);
>
> The crashes for merge_heads.nr == 0.
> (I did not inspect code further up if this is caught before, I think
> it would trigger if
> you and the remote are on an i
On Wed, Jun 29, 2016 at 10:23 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> Is it possible to change the behavior of "git pull
>>> --rebase=true|preserve|interactive" to use a fast forward merge if the
>>> remote branch is ahead and the local branch contains no new commits?
>>
>> Inter
Johannes Schindelin writes:
> It is technically allowed, as per C89, for functions' return type to
> be complete structs (i.e. *not* just pointers to structs), but it is
> bad practice.
Not necessarily.
> This is a very late attempt to contain the damage done by this developer
> in 6d297f8 (Sta
On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano wrote:
> On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
> wrote:
>> This is no RFE but rather recurring thoughts whenever I'm working with
>> commit graphs: a topological index attribute for commit objects would be
>> incredible useful. By "topolo
Johannes Schindelin writes:
> There are a couple of places where return values indicating errors
> are ignored. Let's teach them manners.
>
> Signed-off-by: Johannes Schindelin
> ---
> merge-recursive.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/merge-re
Christian Couder wrote:
> Design discussion about performance
> ~~~
>
> Yeah, it is not efficient to fork/exec a command to just read or write
> one object to or from the external ODB. Batch calls and/or using a
> daemon and/or RPC should be used instead to be able
On Wed, Jun 29, 2016 at 12:47 PM, Jakub Narębski wrote:
>
> I have noticed that the magic pathspec ":/" is described only in RelNotes
> for revision 1.7.6:
> |I think the reason might be that there was no good place to put that
> information in. Nowadays we have gitcli(7) manual page, but perhaps
Hello,
123456789012345678901234567890123456789012345678901234567890123456789012345|
I have noticed that the magic pathspec ":/" is described only in RelNotes
for revision 1.7.6:
|* A magic pathspec ":/" tells a command that limits its operation to the
current directory when ran from a subdirect
W dniu 2016-06-19 o 16:15, Ovatta Bianca pisze:
> I read in every comparison of git vs other version control systems,
> that git does not record differences but takes "snapshots"
> I was wondering what a "snapshot" is ? Does git store at every commit
> the entire files which have been modified eve
Johannes Schindelin writes:
> A truly libified function does not die() just for fun.
The sentence is wasting bits. After all, a helper function in
run-once-and-exit program does not die() just for fun, either.
So what's more interesting to know for the readers?
> As such, the
> recursive merg
On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
wrote:
> This is no RFE but rather recurring thoughts whenever I'm working with
> commit graphs: a topological index attribute for commit objects would be
> incredible useful. By "topological index" I mean a simple integer for which
> following condi
This is no RFE but rather recurring thoughts whenever I'm working with
commit graphs: a topological index attribute for commit objects would be
incredible useful. By "topological index" I mean a simple integer for
which following condition holds true:
if commit C is part of the history of comm
Johannes Schindelin writes:
> It can be puzzling to see that was_tracked() tries to match an index
> entry by name even if cache_name_pos() returned a negative value. Let's
> clarify that cache_name_pos() implicitly looks for stage 0, while we are
> also okay with finding other stages.
>
> Signed
Johannes Schindelin writes:
> To keep the time t3404 requires short (in this developer's Windows
> setup, this single test already takes a painful 8 minutes to pass),
> we avoid a full-blown GPG test and cop out by verifying the message
> displayed to the user upon an 'edit' command.
This is a t
On Wed, Jun 29, 2016 at 7:36 AM, Johannes Schindelin
wrote:
> The vast majority of error messages in Git's source code which report a
> bug use the convention to prefix the message with "BUG:".
> [...]
> Signed-off-by: Johannes Schindelin
> ---
> diff --git a/merge-recursive.c b/merge-recursive.c
Johannes Schindelin writes:
> On Wed, 29 Jun 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > The past tense of "to run" is "run", not "ran".
>>
>> Actually, past tense of the verb "to run" is "ran" ;-) The reason
>> why this patch is still correct is because this is writin
Johannes Schindelin writes:
> It occurred to me that there might be more code locations where finding
> the commit object's body is hand-rolled, and could benefit from using
> the skip_blank_lines() function to handle not-quite-standard but
> still-allowed objects from being processed correctly.
Johannes Schindelin writes:
> From: Junio C Hamano
Did I write this thing?
Having two sets of numbers that illustrated that this is not really
a useful optimization in the bigger picture looks vaguely familiar
(e.g. $gmane/279417), but the numbers are different.
> It feels *slightly* wr
Junio C Hamano writes:
>> Is it possible to change the behavior of "git pull
>> --rebase=true|preserve|interactive" to use a fast forward merge if the
>> remote branch is ahead and the local branch contains no new commits?
>
> Interesting. I do not think of a reason why we shouldn't.
>
> If w
Johannes Schindelin writes:
> While developing patch series, it is a good practice to run the test
> suite from time to time, just to make sure that obvious bugs are caught
> early. With complex patch series, it is common to run `make -j15 -k
> test`, i.e. run the tests in parallel and not stop a
Johannes Schindelin writes:
> On Tue, 28 Jun 2016, Junio C Hamano wrote:
>
>> * jk/ansi-color (2016-06-23) 7 commits
>> (merged to 'next' on 2016-06-28 at 354989c)
>> + color: support strike-through attribute
>> + color: support "italic" attribute
>> + color: allow "no-" for negating attribu
Nicolas Pitre writes:
> To make it clearer, here's a patch on top of pu that fixes all the
> issues I think are remaining. All tests pass now.
>
> diff --git a/sideband.c b/sideband.c
> index 36a032f..0e6c6df 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -23,10 +23,8 @@ int recv_sideband(con
neul...@dakosy.de writes:
> since I have added "pull.rebase=preserve" to my global configuration I
> wonder why "git pull" also trys to rebase if a fast forward merge is
> possible.
>
> A fast forward merge would speed up every pull if your local branch
> contains no new commits and the remote
Hi,
since I have added "pull.rebase=preserve" to my global configuration I
wonder why "git pull" also trys to rebase if a fast forward merge is
possible.
A fast forward merge would speed up every pull if your local branch
contains no new commits and the remote branch is ahead. The result wou
Hey Johannes,
Very minor nits.
On Wed, Jun 29, 2016 at 8:01 PM, Johannes Schindelin
wrote:
> The past tense of "to run" is "run", not "ran".
Past tense of "to run" is "ran" while past participle is "to run".
Past tense: He ran.
Past Participle: He has to run.
> Signed-off-by: Johannes Schinde
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> The following didn't work as expected:
Sorry for being slow (not in response but in understanding), but
let's examine the expectation first.
> - In a middle of a merge
> - merge.renormalize is true,
gitattributes(5) tells us that this wo
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > The past tense of "to run" is "run", not "ran".
>
> Actually, past tense of the verb "to run" is "ran" ;-) The reason
> why this patch is still correct is because this is writing in
> passive voice, where you want
Johannes Schindelin writes:
> The past tense of "to run" is "run", not "ran".
Actually, past tense of the verb "to run" is "ran" ;-) The reason
why this patch is still correct is because this is writing in
passive voice, where you want "be + past participle", and the past
participle of the verb
Hi,
On Wed, 29 Jun 2016, Johannes Schindelin wrote:
> diff --git a/imap-send.c b/imap-send.c
> index 938c691..cd39805 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -511,7 +511,7 @@ static int nfsnprintf(char *buf, int blen, const char
> *fmt, ...)
>
> va_start(va, fmt);
> if
Mark warnings, errors and other messages that are interpolated for
translation.
We must call sprintf() before calling die() and in few other
circumstances in order to interpolation take place.
Signed-off-by: Vasco Almeida
---
git-send-email.perl | 71
Signed-off-by: Vasco Almeida
---
git-difftool.perl | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index ebd13ba..de8d783 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -22,6 +22,7 @@ use File::Path qw(mkpath
Mark warnings, errors and other messages for translation.
Signed-off-by: Vasco Almeida
---
git-send-email.perl | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 2521832..e7f712e 100755
--- a/
Mark message of edit_hunk_manually displayed in the editing file when
user chooses 'e' option. The message had to be unfolded to allow
translation of the $participle verb.
Some messages end up being exactly the same for some uses cases, but
left it for easier change in the future, e.g., wanting t
Mark strings often displayed to user for translation.
Signed-off-by: Vasco Almeida
---
git-send-email.perl | 53 +++--
1 file changed, 31 insertions(+), 22 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 6958785..2521832
Use of sprintf following die or error_msg is necessary for placeholder
substitution take place.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interac
Mark messages in some perl scripts for translation.
Since v1, adds brackets so parameter grouping of sprintf parameters is easier
to see.
Interdiff included below.
Vasco Almeida (11):
i18n: add--interactive: mark strings for translation
i18n: add--interactive: mark simple here documents for
Mark plural strings for translation. Unfold each action case in one
entire sentence.
Pass new keyword for xgettext to extract.
Update test to include new subrotine Q__() for plural strings handling.
Signed-off-by: Vasco Almeida
---
Makefile | 3 ++-
git-add--interactive.perl
Mark message assembled in place for translation, unfolding each use case
for each entry in the %patch_modes hash table.
Previously, this script relied on whether $patch_mode was set to run the
command patch_update_cmd() or show status and loop the main loop. Now,
it uses $cmd to indicate we must r
Mark messages in here document without interpolation for translation.
Marking for translation by removing here documents this way, rather than
take advantage of "print __ << EOF" way, makes other instances of help
messages in clean.c match the first two in this file. Otherwise,
reusing here docum
Mark simple strings (without interpolation) for translation.
Brackets around first parameter of ternary operator is necessary because
otherwise xgettext fails to extract strings marked for translation from
the rest of the file.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 68 +++
Mark help message of help_patch_cmd for translation. The message must
be unfolded to be free of variables so we can have high quality
translations.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 65 +++
1 file changed, 54 insertions(+),
To keep the time t3404 requires short (in this developer's Windows
setup, this single test already takes a painful 8 minutes to pass),
we avoid a full-blown GPG test and cop out by verifying the message
displayed to the user upon an 'edit' command.
Signed-off-by: Johannes Schindelin
---
t/t3404-
The past tense of "to run" is "run", not "ran".
Signed-off-by: Johannes Schindelin
---
t/t3404-rebase-interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 66348f1..c7ea8ba 100755
--- a/t/t3404-rebas
I meant to send the first patch much earlier, but got side-tracked
before I could add the --gpg-sign test.
This is just another patch series in preparation for the rebase--helper
(to be precise, this is the seventh out of fourteen patch series that
have not yet been merged to master; Six are alrea
When trying to match a pattern in the commit subject, simply skip leading
blank lines in the commit message. This is consistent with the
pretty-printing machinery: it silently ignores leading blank lines in the
commit object's body.
Signed-off-by: Johannes Schindelin
---
sha1_name.c | 3 ++-
1 f
While it is not recommended, `git fsck` says that:
Not having a body is not a crime [...]
... which means that we cannot assume that the commit buffer contains an
empty line to separate header from body (essentially saying that there
is only a header).
So let's tread carefully here.
Sig
When there are blank lines at the beginning of a commit message, the
pretty printing machinery already skips them when showing a commit
subject (or the complete commit message). We shall henceforth do the
same when reporting the commit subject after the user called
git reset --hard
Signe
Just like we already taught the find_commit_subject() function (to make
it consistent with the code in pretty.c), we now simply skip leading
blank lines of the commit message.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --g
Consistent with the pretty-printing machinery, we skip leading blank
lines (if any) of existing commit messages.
While Git itself only produces commit objects with a single empty line
between commit header and commit message, it is legal to have more than
one blank line (i.e. lines containing only
These patches are on top of js/find-commit-subject-ignore-leading-blanks
(whether you want to put them into the same topic branch before merging
or put them into their own add-on topic branch does not really matter to
me).
It occurred to me that there might be more code locations where finding
the
Hi Patrick,
On Wed, 29 Jun 2016, Patrick Steinhardt wrote:
> When we abort an interactive rebase we do so by calling
> `die_abort`, which cleans up after us by removing the rebase
> state directory. If the user has requested to use the autostash
> feature, though, the state directory may also con
Hi Johannes,
No.
Another thing I've found is that these commits have different timestamp
in the "Author" and "Committer" lines. The "Committer" lines have
correct timestamps, and the "Author" timestamp is wrong.
Best wishes,
Andrei Faber
On 29/06/2016 18:45, Johannes Schindelin wrote:
Hi A
Dear List,
We have several release branches as well as a master branch where the
active development happens.
Old releases are maintained with important bug fixes or even new features
in our case. It sometimes means that we need to cherry-pick commits across
branches, like from master to a specifi
Hi Junio,
On Tue, 28 Jun 2016, Junio C Hamano wrote:
> * jk/ansi-color (2016-06-23) 7 commits
> (merged to 'next' on 2016-06-28 at 354989c)
> + color: support strike-through attribute
> + color: support "italic" attribute
> + color: allow "no-" for negating attributes
> + color: refactor pa
Hi Andrei,
On Wed, 29 Jun 2016, Andrei Faber wrote:
> I've noticed that git history contains series of commits with exactly
> the same time, despite the real commit time of these commits was
> different. All these commit were made using the git gui tool. I'm the
> only developer in this project.
Hi Yannis,
On Wed, 29 Jun 2016, Ioannis Kappas wrote:
> Johannes Schindelin gmx.de> writes:
>
> > I just re-uploaded new packages, after rebuilding them and making sure
> > that the patch was actually applied.
> >
> > May I ask you to re-test, just to make extra sure that the bug in
> > questi
From: Junio C Hamano
Instead of spawning merge-recursive via run_command() in
run_fallback_merge_recursive(), make a direct call to the internal
merge_recursive_generic().
Here is a quick benchmark result, applying a patch for b4391657
(merge: drop 'git merge HEAD ' syntax, 2015-03-25)
that was
It is possible that a tree cannot be written (think: disk full). We
will want to give the caller a chance to clean up instead of letting
the program die() in such a case.
Signed-off-by: Johannes Schindelin
---
merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
The recursive merge machinery is supposed to be a library function, i.e.
it should return an error when it fails. Originally the functions were
part of the builtin "merge-recursive", though, where it was simpler to
call die() and be done with error handling.
The existing callers were already prepa
A truly libified function does not die() just for fun. As such, the
recursive merge will convert all die() calls to return -1 instead in the
next commits, giving the caller a chance at least to print some helpful
message.
Let's prepare the builtins for this fatal error condition, even if we do
not
We are about to libify the recursive merge machinery, where we only
die() in case of a bug or memory contention. To that end, we must heed
negative return values as indicating errors.
This requires our functions to be careful to pass through error
conditions in call chains, and for quite a few fun
There are a couple of places where return values indicating errors
are ignored. Let's teach them manners.
Signed-off-by: Johannes Schindelin
---
merge-recursive.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index bcb53f0..c
It is technically allowed, as per C89, for functions' return type to
be complete structs (i.e. *not* just pointers to structs), but it is
bad practice.
This is a very late attempt to contain the damage done by this developer
in 6d297f8 (Status update on merge-recursive in C, 2006-07-08) which
intr
The vast majority of error messages in Git's source code which report a
bug use the convention to prefix the message with "BUG:".
As part of cleaning up merge-recursive to stop die()ing except in case of
detected bugs, let's just make the remainder of the bug reports consistent
with the de facto r
It can be puzzling to see that was_tracked() tries to match an index
entry by name even if cache_name_pos() returned a negative value. Let's
clarify that cache_name_pos() implicitly looks for stage 0, while we are
also okay with finding other stages.
Signed-off-by: Johannes Schindelin
---
merge-
1 - 100 of 108 matches
Mail list logo
