On Tue, Mar 20, 2018 at 11:22:02PM -0400, Dakota Hawkins wrote:
> 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
On Tue, Mar 20, 2018 at 05:41:52PM +0100, Duy Nguyen wrote:
> > +The rules by which the pattern matches paths are the same as in
> > +`.gitignore` files (see linkgit:gitignore[5]), with a few exceptions:
> > +
> > + - negative patterns are forbidden
>
> After 8b1bd02415 (Make !pattern in .gitatt
Hi Johannes,
Thanks for the feedback. Thanks to you, I realized my proposal was
a bit ambitious. Both git-stash and git-rebase are big
commitment. After much analyzing, I found out I cannot complete
both in the given time frame. So, I decided to stick to one and
complete it. I decided to stick wit
On Tue, Mar 20, 2018 at 10:52:16PM +, Ramsay Jones wrote:
> > Maybe too clever, but I think you could just do:
> >
> > unsigned int saved_namelen = 0;
> > ...
> > saved_namelen = ce_namelen(ce);
> > ...
> > if (saved_namelen)
> > ce->ce_namelen = saved_namelen;
> > ce->ce_fl
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:
($COLOR?\|$CO
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 patches).
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 the
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
1 file
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 ...
| |
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 rear
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 a/contrib/diff-h
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 "-
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
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" information. A
>>> git-blame of git-rebase--interactive--lib.sh show
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 (co
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]. Unfortunate
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 ce_write_entry(git_SHA_C
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, &size, &eaten);
>> if (!buf)
>> ret = strbuf_error(_("missing object %s for %s"),
>> oid_to_hex(oid), ref->refname);
>> else if (!*ob
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
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 vario
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, &size, &eaten);
> if (!buf)
> ret = strbuf_error(_
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:
b4e00f7306a1 ("packfile: ref
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 t
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 would convert "git stash list"
below?
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
> >> $USERNAME@$REPO_UUID. Now git-svn behaves like git-co
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 that
>> file as having arisen spontaneously fro
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. The functions are
>> those that exist in git-r
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 created from the b
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 insertions(+), 1000 deletion
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
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 | 1 +
Makef
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 I'
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
dOPTTpV8/edit?u
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 abbr
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 2/2 changes into my
>> "rebas
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
>>> packfile, and how to interpret them? I found
>>>
>>> h
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 bi
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 --recreate-merges.
>
> As indicated in a
On 20/03/18 17:34, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>>> + if (!keep_empty && is_empty)
>>> strbuf_addf(&buf, "%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
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.
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 this case, there is no
> point in disp
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
https://github.com/git/git/blob/master/Documentation/technical/pack-format.txt
docu
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
read the size in que
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() calls from ref-filter forma
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 b/ref-filter.c
> @@ -596,19 +603,24 @@ static int is_
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 = e->size_ == size;
>
> A quite similar co
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 whos
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", "gi
Johannes Schindelin writes:
>> +if (!keep_empty && is_empty)
>> strbuf_addf(&buf, "%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 (is_empty || !(commit->obje
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
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 various topics.
Thanks for r
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 we saw a pathspec '.'
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
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 work
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 _great_ if gitattri
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 like
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 just spitballing h
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
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
Only commit messages were updated since last review (there was no
comments about the code).
Thank you!
Olga
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 further
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 ne
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 (the
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 show_ref_array_item()
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 -1
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 the packfile itself, but the
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 se
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 Mon, 19 Mar 2018, Junio C Hamano 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 the packfile itself, but the "compressed delta data" seems
largely undocumented. The
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 the --recreate-merges
patches
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 cherry-picks. Fix this by keeping
> the
... 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
> >
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(&revs, NU
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
> --
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, https://github.com/jkstrauss/git-bug/
> >
> > There seem t
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 [
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.
>> > > >
>> > > > I'm admitte
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 such a behavior, as it disag
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 --merge stops for the
user to r
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" --signoff' which is useful when pr
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 file changed, 2 insertions(+)
diff --git a/git-rebase.sh
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 depends on those fixes. The
third
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 now
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 o
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 marked as cherry-picks.
Signed-
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
---
t/t3421-rebase-topology-linear.sh | 1 +
1 file ch
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 failing test for rebase --re
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 8b1b892d72..37b8f13971 100755
--- a/git-rebase.sh
+++ b/git-rebase
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 that are empty or are not marked
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):
rebase --root: stop assuming squ
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 insertion(+)
diff --git a/git-rebase.sh b/git-rebase.sh
ind
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)
>> | keep_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 th
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 c
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 for us to comment if the mar
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 Bur
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
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
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 save a few
> keystrokes.
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 information
>> in the case where the dwim of "git
1 - 100 of 101 matches
Mail list logo
