[PATCH 7/7] diff-highlight: detect --graph by indent

This patch fixes a corner case where diff-highlight may scramble some diffs when combined with --graph. Commit 7e4ffb4c17 (diff-highlight: add support for --graph output, 2016-08-29) taught diff-highlight to skip past the graph characters at the start of each line with this regex:

[PATCH 6/7] diff-highlight: use flush() helper consistently

The current flush() helper only shows the queued diff but does not clear the queue. This is conceptually a bug, but it works because we only call it once at the end of the program. Let's teach it to clear the queue, which will let us use it in more places (one for now, but more in future

[PATCH 5/7] diff-highlight: test graphs with --color

Our tests send git's output directly to files or pipes, so there will never be any color. Let's do at least one --color test to make sure that we can handle this case (which we currently can, but will be an easy thing to mess up when we touch the graph code in a future patch). We'll just cover

[PATCH 3/7] diff-highlight: prefer "echo" to "cat" in tests

We generate a bunch of one-line files whose contents match their names, and then generate our commits by cat-ing those files. Let's just echo the contents directly, which saves some processes. Signed-off-by: Jeff King --- contrib/diff-highlight/t/t9400-diff-highlight.sh | 12

[PATCH 4/7] diff-highlight: test interleaved parallel lines of history

The graph test in t9400 covers the case of two simultaneous branches, but all of the commits during this time are on the right-hand branch. So we test a graph structure like: | | | * commit ... | | but we never see the reverse, a commit on the left-hand branch: | | * | commit ... |

[PATCH 2/7] diff-highlight: use test_tick in graph test

The exact ordering output by Git may depend on the commit timestamps, so let's make sure they're actually monotonically increasing, and not all the same (or worse, subject to how long the test script takes to run). Let's use test_tick to make sure this is stable. Note that we actually have to

[PATCH 1/7] diff-highlight: correct test graph diagram

We actually branch "A" off of "D". The sample "--graph" output is right, but the left-to-right diagram is misleading. Let's fix it. Signed-off-by: Jeff King --- contrib/diff-highlight/t/t9400-diff-highlight.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [BUG] log --graph corrupts patch

On Tue, Mar 20, 2018 at 11:58:14AM -0400, Jeff King wrote: > The issue bisects to 7e4ffb4c17 (diff-highlight: add support for --graph > output, 2016-08-29). I think the problem is the "\s+" at the end of the > $GRAPH regex, which soaks up the space for the context, and accidentally > treats the

Great News!!!

We have a great about your E-mail address!!! You Won $950,500.00 USD on Amnesty International UK online E-mail Promotion. For more details about your prize claims, file with the following; Names: Country: Tel: Regards, Mr. David Ford

Re: [RFC PATCH 0/3] rebase-interactive

On Tue, Mar 20, 2018 at 2:47 PM, Eric Sunshine wrote: > On Tue, Mar 20, 2018 at 5:23 PM, Wink Saville wrote: >> On Tue, Mar 20, 2018 at 2:11 PM, Eric Sunshine >> wrote: >>> A problem with this approach is that it loses "blame"

Re: .gitattributes override behavior (possible bug, or documentation bug)

Thinking about this a little more, I'm now attracted to the idea that its .gitignore that's weird. As I understand it, .gitignore stops recursion when there's a directory match (`somedir/`) but also explicitly allows nested .gitnore file _as well as_ exclusion (`!*.txt`). So, in the following

Re: [PATCH 0/2] -Wuninitialized

On 20/03/18 14:46, Johannes Schindelin wrote: > Hi Ramsay, > > On Mon, 19 Mar 2018, Ramsay Jones wrote: > >> This series removes all 'self-initialised' variables (ie. var = >> var;). This construct has been used to silence gcc >> '-W[maybe-]uninitialized' warnings in the past [1].

Re: [PATCH 2/2] read-cache: fix an -Wmaybe-uninitialized warning

On 20/03/18 04:36, Jeff King wrote: > On Mon, Mar 19, 2018 at 05:56:11PM +, Ramsay Jones wrote: > [snip] >> diff --git a/read-cache.c b/read-cache.c >> index 2eb81a66b..49607ddcd 100644 >> --- a/read-cache.c >> +++ b/read-cache.c >> @@ -2104,13 +2104,15 @@ static int

Re: [PATCH v4 5/5] ref-filter: get_ref_atom_value() error handling

On Tue, Mar 20, 2018 at 6:30 PM, Junio C Hamano wrote: > Eric Sunshine writes: >> int ret = 0; >> void *buf = get_obj(oid, obj, , ); >> if (!buf) >> ret = strbuf_error(_("missing object %s for %s"), >> oid_to_hex(oid),

(Relief Coordinator, United Nations)

United Nations Compensation Unit, Emergency Relief Coordinator, United Nations. Congratulations Beneficiary, We have been having a meeting for quit sometime now and we just came to a logical conclusion 72 hours ago in affiliation with the World Bank president. Your email was listed among

Re: [PATCH 0/2] -Wuninitialized

On 20/03/18 04:32, Jeff King wrote: > On Mon, Mar 19, 2018 at 05:53:09PM +, Ramsay Jones wrote: >> If we now add a patch to remove all self-initialization, which would be the >> first patch plus the obvious change to 'saved_namelen' in read-cache.c, then >> note the warnings issued by

Re: [PATCH v4 5/5] ref-filter: get_ref_atom_value() error handling

Eric Sunshine writes: > Overall, with the need for resource cleanup, this function becomes > unusually noisy after this change. It could be tamed by doing > something like this: > > int ret = 0; > void *buf = get_obj(oid, obj, , ); > if (!buf) > ret =

Re: [PATCH] sha1_name: use bsearch_hash() for abbreviations

On Tue, 20 Mar 2018 16:03:25 -0400 Derrick Stolee wrote: > This patch updates the abbreviation code to use bsearch_hash() as defined > in [1]. It gets a nice speedup since the old implementation did not use > the fanout table at all. You can refer to the patch as:

What's cooking in git.git (Mar 2018, #04; Tue, 20)

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. Hopefully 2.17-rc1 can be tagged

Re: [GSoC] Convert “git stash” to builtin proposal

Hi, On Tue, Mar 20, 2018 at 9:09 PM, Paul-Sebastian Ungureanu wrote: > > * Convert function: this step is basically makes up the goal of this > project. Could you explain a bit more how you would convert a function? Or could you explain for example how you

Re: [PATCH v2 2/2] git-svn: allow empty email-address in authors-prog and authors-file

Andreas Heiduk wrote: > Am 19.03.2018 um 00:04 schrieb Eric Wong: > > Andreas Heiduk wrote: > >> The email address in --authors-file and --authors-prog can be empty but > >> git-svn translated it into a syntethic email address in the form > >>

Re: [RFC PATCH 0/3] rebase-interactive

On Tue, Mar 20, 2018 at 5:23 PM, Wink Saville wrote: > On Tue, Mar 20, 2018 at 2:11 PM, Eric Sunshine > wrote: >> A problem with this approach is that it loses "blame" information. A >> git-blame of git-rebase--interactive--lib.sh shows all code in

Re: [RFC PATCH 0/3] rebase-interactive

On Tue, Mar 20, 2018 at 2:11 PM, Eric Sunshine wrote: > On Tue, Mar 20, 2018 at 4:45 PM, Wink Saville wrote: >> Patch 0001 creates a library of functions which can be >> used by git-rebase--interactive and >> git-rebase--interactive--preserve-merges.

Re: [RFC PATCH 0/3] rebase-interactive

On Tue, Mar 20, 2018 at 4:45 PM, Wink Saville wrote: > Patch 0001 creates a library of functions which can be > used by git-rebase--interactive and > git-rebase--interactive--preserve-merges. The functions are > those that exist in git-rebase--interactive.sh plus new > functions

[RFC PATCH 3/3] rebase-interactive: refactor git-rebase--interactive to use library

Refactor git-rebase--interactive to use git-rebase--interactive--lib this simplifies and reduces the size of the code by about 1000 LoC. Signed-off-by: Wink Saville --- git-rebase--interactive.sh | 1019 +--- 1 file changed, 19

[RFC PATCH 1/3] rebase-interactive: create git-rebase--interactive--lib.sh

Create a library that can be used for interactive rebasing by separate scripts. In particular, the current git-rebase--interactive.sh will be reduced to a single function which uses the library and a new file, git-rebase--interactive--preserve-merges.sh will also be a single function that uses the

[RFC PATCH 2/3] rebase-interactive: create git-rebase--interactive--preserve-merges

Extract the code that is executed when $preserve_merges is t from git-rebase--interactive to git-rebase--interactive--preserve-merges.sh. The extracted code uses functions from git-rebase--interactve--lib. Signed-off-by: Wink Saville --- .gitignore

[RFC PATCH 0/3] rebase-interactive

I've not worked on the git sources before and while looking into fixing test_expect_failure 'exchange two commits with -p' in t3404-rebase-interactive.sh, I found it difficult to understand the git testing infracture and git-rebase--interactive.sh. So as part of learning my way around I thought

[GSoC] Convert “git stash” to builtin proposal

Hello, I have completed the first draft of my proposal for the Google Summer of Code, which can be found at [1] or below for those who prefer the text version. Any feedback is greatly appreciated. Thanks! [1] https://docs.google.com/document/d/1TtdD7zgUsEOszHG5HX1at4zHMDsPmSBYWqy

[PATCH] sha1_name: use bsearch_hash() for abbreviations

This patch updates the abbreviation code to use bsearch_hash() as defined in [1]. It gets a nice speedup since the old implementation did not use the fanout table at all. One caveat about the patch: there is a place where I cast a sha1 hash into a struct object_id pointer. This is because the

Re: [PATCH 0/2] rebase --recreate-merges --keep-empty: don't prune empty

Phillip Wood writes: > On 20/03/18 15:42, Johannes Schindelin wrote: > ... >> As indicated in another reply, I'd rather rebase the --recreate-merges >> patches on top of your --keep-empty patch series. This obviously means >> that I would fold essentially all of your

Re: Understanding Binary Deltas within Packfile

On Tue, Mar 20, 2018 at 7:34 PM, Luke Robison wrote: > On 3/20/2018 11:03 AM, Duy Nguyen wrote: >> >> On Tue, Mar 20, 2018 at 4:43 PM, Luke Robison >> wrote: >>> >>> Is there any documentation of the contents of the binary delta datain a >>>

Re: [PATCH v2 3/3] rebase --keep-empty: always use interactive rebase

On 20/03/18 16:08, Johannes Schindelin wrote: > Hi Phillip, > > On Tue, 20 Mar 2018, Phillip Wood wrote: > >> git-rebase--am.sh | 79 >> --- > > Those are a lot of changes, but pretty much all of it is a change in > indentation. Yes it's a

Re: [PATCH 0/2] rebase --recreate-merges --keep-empty: don't prune empty

On 20/03/18 15:42, Johannes Schindelin wrote: > Hi Phillip, > > On Tue, 20 Mar 2018, Phillip Wood wrote: > >> From: Phillip Wood >> >> These patches apply on top of js/rebase-recreate-merge. They extend >> the --keep-empty fix from maint [1] to work with

Re: [PATCH 2/3] rebase -i --keep-empty: don't prune empty commits

On 20/03/18 17:34, Junio C Hamano wrote: > Johannes Schindelin writes: > >>> + if (!keep_empty && is_empty) >>> strbuf_addf(, "%c ", comment_line_char); > > We are not trying to preserve an empty one, and have found an empty > one, so we

Re: [GSoC][PATCH v6] parse-options: do not show usage upon invalid option value

On Tue, Mar 20, 2018 at 1:50 PM, Paul-Sebastian Ungureanu wrote: > Usually, the usage should be shown only if the user does not know what > options are available. If the user specifies an invalid value, the user > is already aware of the available options. In

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($14.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Re: Understanding Binary Deltas within Packfile

On 3/20/2018 11:03 AM, Duy Nguyen wrote: On Tue, Mar 20, 2018 at 4:43 PM, Luke Robison wrote: Is there any documentation of the contents of the binary delta datain a packfile, and how to interpret them? I found

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

Duy Nguyen writes: > This "size" field contains the delta size if the in-pack object is a > delta. So blindly falling back to object_sha1_info() which returns the > canonical object size is definitely wrong. Yup. Also we need to be careful when going back to the packfile to

Re: [PATCH v4 5/5] ref-filter: get_ref_atom_value() error handling

On Tue, Mar 20, 2018 at 12:05 PM, Olga Telezhnaya wrote: > ref-filter: get_ref_atom_value() error handling This doesn't tell us much about what this patch is doing. Perhaps a better subject would be: ref-filter: libify get_ref_atom_value() > Finish removing die()

Re: [PATCH v4 2/5] ref-filter: add return value && strbuf to handlers

On Tue, Mar 20, 2018 at 12:05 PM, Olga Telezhnaya wrote: > Continue removing die() calls from ref-filter formatting logic, > so that it could be used by other commands. > [...] > Signed-off-by: Olga Telezhnaia > --- > diff --git a/ref-filter.c

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

On Mon, Mar 19, 2018 at 5:43 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> +static inline void oe_set_size(struct object_entry *e, >> +unsigned long size) >> +{ >> + e->size_ = size; >> + e->size_valid =

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

On Mon, Mar 19, 2018 at 01:10:49PM -0700, Junio C Hamano wrote: > > ... I was trying to exercise this > > code the other day by reducing size_ field down to 4 bits, and a > > couple tests broke but I still don't understand how. > > Off by one? Two or more copies of the same objects available

[GSoC][PATCH v6] parse-options: do not show usage upon invalid option value

Usually, the usage should be shown only if the user does not know what options are available. If the user specifies an invalid value, the user is already aware of the available options. In this case, there is no point in displaying the usage anymore. This patch applies to "git tag --contains",

Re: [PATCH 2/3] rebase -i --keep-empty: don't prune empty commits

Johannes Schindelin writes: >> +if (!keep_empty && is_empty) >> strbuf_addf(, "%c ", comment_line_char); We are not trying to preserve an empty one, and have found an empty one, so we comment it out, and then... >> +if

We have deposited the check of your fund (2.500,000,00USD) through Money Gram

We have deposited the check of your fund (2.500,000,00USD) through Money Gram after our finally meeting regarding your funds. All you will do is to contact Money Gram director Mr. Christ Orji via E-mail(moneygramfi...@outlook.com) He will give you more direction on how you will be receiving the

Re: PATCH 1/2] -Wuninitialized: remove some 'init-self' workarounds

Ramsay Jones writes: > You may not have noticed that I messed up the Subject line of > this patch - I managed to drop the '[' character in the patch > prefix string. :( I did notice the lack of '[' while reading, and then totally forgot by the time I started queuing

Re: [PATCH v5 2/3] stash push: avoid printing errors

Thomas Gummerer writes: > ... > Fix this by avoiding the 'git clean' if a pathspec is given, and use the > pipeline that's used for pathspec mode to get rid of the untracked files > as well. That made me wonder if we can get rid of 'git clean' altogether by pretending that

Great News!!

We have a great about your E-mail address!!! You Won $950,500.00 USD on Amnesty International UK online E-mail Promotion. For more details about your prize claims, file with the following; Names: Country: Tel: Regards, Mr. David Ford

Re: [PATCH 0/2] routines to generate JSON data

On 3/20/2018 1:42 AM, Jeff King wrote: On Mon, Mar 19, 2018 at 06:19:26AM -0400, Jeff Hostetler wrote: To make the above work, I think you'd have to store a little more state. E.g., the "array_append" functions check "out->len" to see if they need to add a separating comma. That wouldn't

Re: [PATCH] doc/gitattributes: mention non-recursive behavior

On Tue, Mar 20, 2018 at 5:14 AM, Jeff King wrote: > On Tue, Mar 20, 2018 at 12:04:11AM -0400, Jeff King wrote: > >> > I guess my takeaway is that it would be _good_ if the gitattributes >> > documentation contained the caveat about not matching directories >> > recursively, but

Re: [RFC][GSoC] Project proposal: convert interactive rebase to C

Hi Alban, thank you for your proposal! I will only comment on the parts that I feel could use improvement, the rest is fine by me. On Sat, 17 Mar 2018, Alban Gruin wrote: > APPROXIMATIVE TIMELINE > > Community bonding — April 23, 2018 – May 14, 2018 > During the community bonding, I would

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Tue, Mar 20, 2018 at 5:40 AM, Jeff King wrote: > On Tue, Mar 20, 2018 at 12:25:27AM -0400, Dakota Hawkins wrote: > >> > Right. The technical reason is mostly "that is not how it was designed, >> > and it would possibly break some corner cases if we switched it now". >> >> I'm

CAN I TRUST YOU??

Good Day, How are u doing today ? Apologies! I am a military woman ,seeking your kind assistance to move the sum of ($7M USD) to you, as far as i can be assured that my money will be safe in your care until i complete my service here in Afghanistan and come over next month. This is legitimate, and

Re: [PATCH v2 3/3] rebase --keep-empty: always use interactive rebase

Hi Phillip, On Tue, 20 Mar 2018, Phillip Wood wrote: > git-rebase--am.sh | 79 > --- Those are a lot of changes, but pretty much all of it is a change in indentation. All three patches look good to me. Thanks, Dscho

[PATCH v4 0/5] ref-filter: remove die() calls from formatting logic

Only commit messages were updated since last review (there was no comments about the code). Thank you! Olga

[PATCH v4 4/5] ref-filter: add return value to parsers

Continue removing die() calls from ref-filter formatting logic, so that it could be used by other commands. Change the signature of parsers by adding return value and strbuf parameter for error message. Return value equals 0 upon success and -1 upon failure (there could be more error codes

[PATCH v4 2/5] ref-filter: add return value && strbuf to handlers

Continue removing die() calls from ref-filter formatting logic, so that it could be used by other commands. Change the signature of handlers by adding return value and strbuf parameter for errors. Return value equals 0 upon success and -1 upon failure (there could be more error codes further if

[PATCH v4 5/5] ref-filter: get_ref_atom_value() error handling

Finish removing die() calls from ref-filter formatting logic, so that it could be used by other commands. Change the signature of get_ref_atom_value() and underlying functions by adding return value and strbuf parameter for error message. Return value equals 0 upon success and -1 upon failure

[PATCH v4 1/5] ref-filter: start adding strbufs with errors

This is a first step in removing die() calls from ref-filter formatting logic, so that it could be used by other commands that do not want to die during formatting process. die() calls related to bugs in code will not be touched in this patch. Everything would be the same for

[PATCH v4 3/5] ref-filter: change parsing function error handling

Continue removing die() calls from ref-filter formatting logic, so that it could be used by other commands. Change the signature of parse_ref_filter_atom() by adding strbuf parameter for error message. The function returns the position in the used_atom[] array (as before) for the given atom, or

Re: Understanding Binary Deltas within Packfile

On Tue, Mar 20, 2018 at 4:43 PM, Luke Robison wrote: > Is there any documentation of the contents of the binary delta datain a > packfile, and how to interpret them? I found > https://github.com/git/git/blob/master/Documentation/technical/pack-format.txt > documenting

Re: [BUG] log --graph corrupts patch

On Tue, Mar 20, 2018 at 09:58:14AM +, Phillip Wood wrote: > > Are you using any exotic filters for your pager? If you use "git > > --no-pager" does the problem persist? > > Hi Peff, thanks for taking the time to check this, I had forgotten about > the pager. I'm using diff-highlight and it

RE: Bug With git rebase -p

Perfect. Thank you. -Original Message- From: Johannes Schindelin [mailto:johannes.schinde...@gmx.de] Sent: Tuesday, March 20, 2018 10:53 AM To: Junio C Hamano Cc: Joseph Strauss ; git@vger.kernel.org Subject: Re: Bug With git rebase -p Hi, On

Understanding Binary Deltas within Packfile

Is there any documentation of the contents of the binary delta datain a packfile, and how to interpret them? I found https://github.com/git/git/blob/master/Documentation/technical/pack-format.txt documenting the packfile itself, but the "compressed delta data" seems largely undocumented. The

Re: [PATCH 0/2] rebase --recreate-merges --keep-empty: don't prune empty

Hi Phillip, On Tue, 20 Mar 2018, Phillip Wood wrote: > From: Phillip Wood > > These patches apply on top of js/rebase-recreate-merge. They extend > the --keep-empty fix from maint [1] to work with --recreate-merges. As indicated in another reply, I'd rather rebase

Re: [PATCH 2/2] rebase --recreate-merges --keep-empty: don't prune empty commits

Hi Phillip, On Tue, 20 Mar 2018, Phillip Wood wrote: > From: Phillip Wood > > If there are empty commits on the left hand side of $upstream...HEAD > then the empty commits on the right hand side that we want to keep are > pruned because they are marked as

Re: [PATCH 0/3] rebase --keep-empty/--root fixes

... and now also Cc:ing the list and Junio... On Tue, 20 Mar 2018, Johannes Schindelin wrote: > Hi Phillip, > > On Tue, 20 Mar 2018, Phillip Wood wrote: > > > Phillip Wood (3): > > rebase --root: stop assuming squash_onto is unset > > rebase -i --keep-empty: don't prune empty commits > >

Re: [PATCH 2/3] rebase -i --keep-empty: don't prune empty commits

Hi Phillip, On Tue, 20 Mar 2018, Phillip Wood wrote: > diff --git a/sequencer.c b/sequencer.c > index 4d3f60594c..96ff812c8d 100644 > --- a/sequencer.c > +++ b/sequencer.c > @@ -2470,7 +2470,7 @@ int sequencer_make_script(FILE *out, int argc, const > char **argv, > init_revisions(, NULL);

Re: [RFC] [GSoC] Project proposal: convert scripts to builtins

Hi Pratik, thank you so much for posting this inline, to make it easier to review. I will quote only on specific parts below; Please just assume that I like the other parts and have nothing to add. On Tue, 20 Mar 2018, Pratik Karki wrote: > > Timeline and Development Cycle >

Re: Bug With git rebase -p

Hi, On Mon, 19 Mar 2018, Junio C Hamano wrote: > Joseph Strauss writes: > > > I found the following erroneous behavior with "git rebase -p". > > > > My current version is git version 2.16.2.windows.1 > > > > I made an example at GitHub,

Re: [PATCH 0/2] -Wuninitialized

Hi Ramsay, On Mon, 19 Mar 2018, Ramsay Jones wrote: > This series removes all 'self-initialised' variables (ie. var = > var;). This construct has been used to silence gcc > '-W[maybe-]uninitialized' warnings in the past [1]. Unfortunately, this > construct causes warnings to be issued by MSVC

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Igor Djordjevic writes: > Hi Sergey, > > On 19/03/2018 06:44, Sergey Organov wrote: >> >> > > > > > Second side note: if we can fast-forward, currently we prefer >> > > > > > that, and I think we should keep that behavior with -R, too. >> > > > > >> > > > > I agree.

Re: [PATCH] mingw: abort on invalid strftime formats

Hi Junio, On Mon, 19 Mar 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Windows, strftime() does not silently ignore invalid formats, but > > warns about them and then returns 0 and sets errno to EINVAL. > > > > Unfortunately, Git does not expect

[PATCH v2 3/3] rebase --keep-empty: always use interactive rebase

From: Phillip Wood rebase --merge accepts --keep-empty but just ignores it, by using an implicit interactive rebase the user still gets the rename detection of a merge based rebase but with with --keep-empty support. If rebase --keep-empty without --interactive or

[PATCH v2 1/3] rebase: extend --signoff support

From: Phillip Wood Allow --signoff to be used with --interactive and --merge. In interactive mode only commits marked to be picked, edited or reworded will be signed off. The main motivation for this patch was to allow one to run 'git rebase --exec "make check"

[PATCH v2 2/3] rebase -p: error out if --signoff is given

From: Phillip Wood rebase --preserve-merges does not support --signoff so error out rather than just silently ignoring it so that the user knows the commits will not be signed off. Signed-off-by: Phillip Wood --- git-rebase.sh | 2 ++ 1

[PATCH v2 0/3] rebase: extend --signoff support

From: Phillip Wood Thanks for the feedback on v1, based on that I've added support for --interacive --signoff and --merge --signoff. I've split this series so the fixes from patch two in the last verion are now in a separate series [1]. The tests in this version

Re: [PATCH] filter-branch: use printf instead of echo -e

Il 20/03/2018 10:53, Ian Campbell ha scritto: On Tue, 2018-03-20 at 00:22 -0400, Jeff King wrote: Author cc'd in case there's something more interesting going on. That code was written years ago, if I had a good reason at the time I've forgotten what it was and I can't think of a fresh one

Re: [PATCH v5 0/3] stash push -u -- fixes

On 20.03.2018 00:21, Thomas Gummerer wrote: Thanks again Marc for all the testing and Junio for fixing up my brown paper bag copy-pasto. This iteration addresses the breakage Marc noticed with the latest version of the patches, adds some more tests, and moves all the new tests to t3905 instead

[PATCH 2/2] rebase --recreate-merges --keep-empty: don't prune empty commits

From: Phillip Wood If there are empty commits on the left hand side of $upstream...HEAD then the empty commits on the right hand side that we want to keep are pruned because they are marked as cherry-picks. Fix this by keeping the commits that are empty or are not

[PATCH 1/2] add failing test for rebase --recreate-merges --keep-empty

From: Phillip Wood If there are empty commits on the left hand side of $upstream...HEAD then the empty commits on the right hand side that we want to keep are being pruned. This will be fixed in the next commit. Signed-off-by: Phillip Wood

[PATCH 0/2] rebase --recreate-merges --keep-empty: don't prune empty

From: Phillip Wood These patches apply on top of js/rebase-recreate-merge. They extend the --keep-empty fix from maint [1] to work with --recreate-merges. [1] https://public-inbox.org/git/20180320100315.15261-3-phillip.w...@talktalk.net/T/#u Phillip Wood (2): add

[PATCH 0/3] rebase --keep-empty/--root fixes

From: Phillip Wood These patches are based on top of maint. The first two are a reworking of "[PATCH 2/2] rebase --root -k: fix when root commit is empty" [1] [1] https://public-inbox.org/git/2018031427.14217-2-phillip.w...@talktalk.net/ Phillip Wood (3):

[PATCH 3/3] rebase: respect --no-keep-empty

From: Phillip Wood $OPT_SPEC has always allowed --no-keep-empty so lets start handling it. Signed-off-by: Phillip Wood --- git-rebase.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/git-rebase.sh b/git-rebase.sh index

[PATCH 2/3] rebase -i --keep-empty: don't prune empty commits

From: Phillip Wood If there are empty commits on the left hand side of $upstream...HEAD then the empty commits on the right hand side that we want to keep are pruned by --cherry-pick. Fix this by using --cherry-mark instead of --cherry-pick and keeping the commits

[PATCH 1/3] rebase --root: stop assuming squash_onto is unset

From: Phillip Wood If the user set the environment variable 'squash_onto', the 'rebase' command would erroneously assume that the user passed the option '--root'. Signed-off-by: Phillip Wood --- git-rebase.sh | 1 + 1 file changed, 1

Re: [BUG] log --graph corrupts patch

On 20/03/18 06:09, Jeff King wrote: > On Mon, Mar 19, 2018 at 10:21:56AM +, Phillip Wood wrote: > >> I've just been reviewing some patches with 'git log --graph --patch' and >> came across what looked like a bug: >> >> | @@ -272,6 +272,9 @@ do >> | --keep-empty) >> |

Re: [PATCH] filter-branch: use printf instead of echo -e

On Tue, 2018-03-20 at 00:22 -0400, Jeff King wrote: > Author cc'd in case there's something more interesting going on. That code was written years ago, if I had a good reason at the time I've forgotten what it was and I can't think of a fresh one now. Switching to printf seems like a reasonable

Re: [RFC] [GSoC] Project proposal: convert scripts to builtins

Hi, This is my draft for my proposal on "Convert Scripts to builtins" for GSoC. Please review and provide feedback. Cheers, Pratik Karki Convert Scripts to builtins === Abstract Many components of Git are still in the form of shell and Perl scripts. This has

Re: [RFC] [GSoC] Project proposal: convert scripts to builtins

Hi, On Tue, Mar 20, 2018 at 10:00 AM, Pratik Karki wrote: > Hi, > This is my draft for my proposal on "Convert Scripts to builtin" for GSoC. > Please review and provide feedbacks. > > https://gist.github.com/prertik/daaa73a39d3ce30811d9a208043dc235 It would be easier

FROM Mr USMAN ABU

FROM Mr USMAN ABU BILLS AND EXCHANGE MANAGER, In BANK OF AFRICA (B.O.A) Ouagadougou Burkina Faso, IN WEST AFRCA Please i want you to read this later very carefully and please do not joke with this message. I am Mr USMAN AU, the bill and exchange manager in the boa bank of Africa Ouagadougou

[RFC] [GSoC] Project proposal: convert scripts to builtins

Hi, This is my draft for my proposal on "Convert Scripts to builtin" for GSoC. Please review and provide feedbacks. https://gist.github.com/prertik/daaa73a39d3ce30811d9a208043dc235 Cheers, Pratik Karki

[no subject]

my name is Mrs. Alice Walton, I have a mission for you which I intend using for CHARITY email me: ( i...@alicewonders.us ) for more details

Re: [PATCH v4 4/4] worktree: teach "add" to check out existing branches

On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer wrote: > [...] > However we can do a little better than that, and check the branch out if > it is not checked out anywhere else. This will help users who just want > to check an existing branch out into a new worktree, and

Re: [PATCH v4 2/4] worktree: be clearer when "add" dwim-ery kicks in

On Tue, Mar 20, 2018 at 3:26 AM, Eric Sunshine wrote: > On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer wrote: >> Currently there is no indication in the "git worktree add" output that >> a new branch was created. This would be especially useful

Re: [PATCH v4 2/4] worktree: be clearer when "add" dwim-ery kicks in

On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer wrote: > Currently there is no indication in the "git worktree add" output that > a new branch was created. This would be especially useful information > in the case where the dwim of "git worktree add " kicks in, as the >

Re: [PATCH v4 2/4] worktree: be clearer when "add" dwim-ery kicks in

On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer wrote: > Currently there is no indication in the "git worktree add" output that > a new branch was created. This would be especially useful information > in the case where the dwim of "git worktree add " kicks in, as the >

Re: [PATCH v4 1/4] worktree: improve message when creating a new worktree

On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer wrote: > [...] > Fix these inconsistencies, and no longer show the identifier by making > the 'git reset --hard' call quiet, and printing the message directly > from the builtin command instead. > > Signed-off-by: Thomas

Re: [BUG] log --graph corrupts patch

On Mon, Mar 19, 2018 at 10:21:56AM +, Phillip Wood wrote: > I've just been reviewing some patches with 'git log --graph --patch' and > came across what looked like a bug: > > | @@ -272,6 +272,9 @@ do > | --keep-empty) > | keep_empty=yes > | ;; > |

  1   2   >