Re: git gui produces series of commits with exactly the same time

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

Re: [PATCH 1/9] Report bugs consistently

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 { -

[PATCH] builtin/apply: include declaration of cmd_apply()

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

[PATCH 3/4] push: accept push options

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

[PATCH 1/4] push options: {pre,post}-receive hook learns about push options

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

[RFC PATCHv1 0/4] Push options in C Git

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

[PATCH 4/4] add a test for push options

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

[PATCH 2/4] receive-pack: implement advertising and receiving push options

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

Re: What's cooking in git.git (Jun 2016, #10; Wed, 29)

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 >

What's cooking in git.git (Jun 2016, #10; Wed, 29)

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

Re: [PATCH 5/5] Skip blank lines when matching ^{/foo}

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.

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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?

Re: [PATCH 1/5] commit -C: skip blank lines at the beginning of the message

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

Re: [PATCH 2/5] sequencer: use skip_blank_lines() to find the commit subject

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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 >>>

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: [RFD] Place to document magic pathspecs like ":/" and pathspec handling

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

Re: [PATCH 9/9] am: make a direct call to merge_recursive

Johannes Schindelin writes: > - cp.git_cmd = 1; > + init_merge_options(); > + > + o.branch1 = "HEAD"; > + his_tree_name = xstrfmt("%.*s", linelen(state->msg), state->msg); > + o.branch2 = his_tree_name; > > - argv_array_pushf(_array,

Re: [RFD] Place to document magic pathspecs like ":/" and pathspec handling

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

Re: [PATCH 8/9] merge-recursive: switch to returning errors instead of dying

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

Re: [PATCH 7/9] merge-recursive: handle return values indicating errors

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) >

Re: topological index field for commit objects

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:

Re: topological index field for commit objects

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 >>

Re: topological index field for commit objects

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

Re: [PATCH 1/9] Report bugs consistently

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

Re: topological index field for commit objects

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

Re: git pull --rebase should use fast forward merge if possible

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

Re: git pull --rebase should use fast forward merge if possible

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

Re: [PATCH 5/9] merge-recursive: avoid returning a wholesale struct

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

Re: topological index field for commit objects

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

Re: [PATCH 4/9] merge_recursive: abort properly upon errors

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,

Re: [RFC/PATCH v2 00/10] Add initial experimental external ODB support

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

Re: [RFD] Place to document magic pathspecs like ":/" and pathspec handling

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)

[RFD] Place to document magic pathspecs like ":/" and pathspec handling

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

Re: Fwd: what is a snapshot?

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

Re: [PATCH 3/9] Prepare the builtins for a libified merge_recursive()

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? >

Re: topological index field for commit objects

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

topological index field for commit objects

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

Re: [PATCH 2/9] merge-recursive: clarify code in was_tracked()

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

Re: [PATCH 2/2] t3404: add a test for the --gpg-sign option

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

Re: [PATCH 1/9] Report bugs consistently

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 >

Re: [PATCH 1/2] t3404: fix another typo

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 >>

Re: [PATCH 0/5] Use skip_blank_lines() for more commit messages

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

Re: [PATCH 9/9] am: make a direct call to merge_recursive

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

Re: git pull --rebase should use fast forward merge if possible

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

Re: [PATCH] t/Makefile: add a rule to re-run previously-failed tests

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

Re: preview: What's cooking in git.git (Jun 2016, #10; Tue, 28)

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:

Re: [PATCH v4] Refactor recv_sideband()

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 @@

Re: git pull --rebase should use fast forward merge if possible

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

git pull --rebase should use fast forward merge if possible

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

Re: [PATCH 1/2] t3404: fix another typo

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. >

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

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

Re: [PATCH 1/2] t3404: fix another typo

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 >

Re: [PATCH 1/2] t3404: fix another typo

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

Re: [PATCH 1/9] Report bugs consistently

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

[PATCH v2 10/11] i18n: send-email: mark string with interpolation for translation

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

[PATCH v2 11/11] i18n: difftool: mark warnings for translation

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 @@

[PATCH v2 09/11] i18n: send-email: mark warnings and errors for translation

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

[PATCH v2 07/11] i18n: add--interactive: mark edit_hunk_manually message for translation

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

[PATCH v2 08/11] i18n: send-email: mark strings for translation

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

[PATCH v2 03/11] i18n: add--interactive: mark strings with interpolation for translation

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

[PATCH v2 00/11] Mark strings in perl script for translation

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

[PATCH v2 04/11] i18n: add--interactive: mark plural strings

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 ++-

[PATCH v2 05/11] i18n: add--interactive: mark message for translation

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

[PATCH v2 02/11] i18n: add--interactive: mark simple here documents for translation

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

[PATCH v2 01/11] i18n: add--interactive: mark strings for translation

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 ---

[PATCH v2 06/11] i18n: add--interactive: i18n of help_patch_cmd

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

[PATCH 2/2] t3404: add a test for the --gpg-sign option

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

[PATCH 1/2] t3404: fix another typo

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

[PATCH 0/2] Late edits to the rebase -i tests

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

[PATCH 5/5] Skip blank lines when matching ^{/foo}

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

[PATCH 4/5] commit -S: avoid invalid pointer with empty message

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.

[PATCH 3/5] reset --hard: skip blank lines when reporting the commit subject

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

[PATCH 2/5] sequencer: use skip_blank_lines() to find the commit subject

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

[PATCH 1/5] commit -C: skip blank lines at the beginning of the message

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

[PATCH 0/5] Use skip_blank_lines() for more commit messages

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

Re: [PATCH v2] rebase -i: restore autostash on abort

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

Re: git gui produces series of commits with exactly the same time

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

git tag --contains for cherry-picks

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

Re: preview: What's cooking in git.git (Jun 2016, #10; Tue, 28)

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

Re: git gui produces series of commits with exactly the same time

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.

Re: git svn clone segmentation faul issue

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 > >

[PATCH 9/9] am: make a direct call to merge_recursive

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,

[PATCH 6/9] merge-recursive: allow write_tree_from_memory() to error out

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

[PATCH 8/9] merge-recursive: switch to returning errors instead of dying

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

[PATCH 3/9] Prepare the builtins for a libified merge_recursive()

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

[PATCH 7/9] merge-recursive: handle return values indicating errors

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

[PATCH 4/9] merge_recursive: abort properly upon errors

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

[PATCH 5/9] merge-recursive: avoid returning a wholesale struct

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

[PATCH 1/9] Report bugs consistently

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

[PATCH 2/9] merge-recursive: clarify code in was_tracked()

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

[PATCH 0/9] Use merge_recursive() directly in the builtin am

This is the long-awaited re-roll of the attempt to avoid spawning merge-recursive from the builtin am and use merge_recursive() directly instead. As indicated in the message of the final commit, the performance improvement is modest, if noticable. The *real* reason for the reroll is that I need

Re: git svn clone segmentation faul issue

Hi Johannes, Johannes Schindelin gmx.de> writes: > > Hi Yannis, > > [...] > > 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 question > is fixed? I confirm

git gui produces series of commits with exactly the same time

Hi everyone, 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. Has anyone experienced the same problem?

Re: git svn clone segmentation faul issue

Hi Eric, Eric Wong 80x24.org> writes: > > Ioannis.Kappas rbs.com wrote: > > Fortunately, a patch has already been submitted to subversion > > with (github) revision > > a074af86c8764404b28ce99d0bedcb668a321408 (at > >

Re: What's happening to the index

"Andy Falanga (afalanga)" writes: > The strange thing now is, after the script exits, I then call "git > fetch" in the recipe. I can see from the output of make that the remote > db is fetched. However, when I call "git show > origin/rpm:path/to/rpm_build_num" from the

  1   2   >