On Mon, Oct 16, 2017 at 11:49:13PM +, brian m. carlson wrote:
> On Mon, Oct 16, 2017 at 11:15:34AM +0900, Junio C Hamano wrote:
> > With a hope that this might help other reviewers, here is the
> > interdiff between "the previous one merged with v2.15-rc1" and "this
> > round applied on v2.15-r
On Mon, Oct 16, 2017 at 07:45:46PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> [..]
>
> diff --git a/builtin/check-ref-format.c b/builtin/check-ref-format.c
> index 1e5f9835f0..4e62852089 100644
> --- a/builtin/check-ref-format.c
> +++ b/builtin/check-ref-format.c
> @@ -38,12 +38,2
On Tue, Oct 17, 2017 at 11:40:17AM +0900, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> >> + setup_git_directory_gently(&nongit);
> >> +
> >> + if (!nongit)
> >> + malformed = (strbuf_check_branch_ref(&sb, arg) ||
> >&g
On Tue, Oct 17, 2017 at 06:21:22PM +0300, Nikolay Yakimov wrote:
> Hello. After updating to a recent git release (2.14, I believe, but
> possibly earlier), setting GIT_EXEC_PATH to multiple directories
> stopped working. It did work before, and I believe the culprit is
> 'git-sh-setup', which uses
On Sat, Sep 23, 2017 at 07:55:56PM +, Christian Couder wrote:
> It is error prone and tiring to use many long environment
> variables to give parameters to the 'run' script.
>
> Let's make it easy to store some parameters in a config
> file and to pass them to the run script.
>
> The GIT_PERF
On Mon, Oct 23, 2017 at 02:52:46PM -0700, Jonathan Nieder wrote:
> Hi,
>
> Kevin Daudt wrote:
>
> > --- a/column.c
> > +++ b/column.c
> > @@ -5,6 +5,7 @@
> > #include "parse-options.h"
> > #include "run-command.h"
> > #
On Tue, Oct 17, 2017 at 03:10:11PM +0200, Johannes Schindelin wrote:
> We meticulously pass the `exclude` flag to the `treat_directory()`
> function so that we can indicate that files in it are excluded rather
> than untracked when recursing.
>
> But we did not yet treat submodules the same way.
>
uot;);
> + }
> }
> }
>
> diff --git a/sequencer.h b/sequencer.h
> index 6f3d3df82..a907c0947 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -24,6 +24,7 @@ struct replay_opts {
> int allow_empty;
> int allow_empty_message;
> int keep_redundant_commits;
> + int keep_existing_origin;
> int verbose;
>
> int mainline;
> --
> 2.14.1
>
I'm wondering if it isn't better to detect that there is already an
origin present and not add another one.
Or are there situations where you do want multiple cherry-pick origins?
Kevin
p repos, git
would complain about a certain object missing or corrupt, where it might
be usefull to find out how it's referenced. Not sure though if this
would work in that case, because the repo is already corrupt.
Kevin
On Tue, Oct 31, 2017 at 10:58:16AM +0100, René Scharfe wrote:
> Cut off any previous content of the file to be rewritten by passing the
> flag O_TRUNC to open(2) instead of calling ftruncate(2) at the end.
> That's easier and shorter.
>
> Signed-off-by: Rene Scharfe
> ---
> sequencer.c | 4 +---
On Tue, Oct 31, 2017 at 10:54:21AM +0100, René Scharfe wrote:
> Reduce code duplication by extracting a function for rewriting an
> existing file.
>
> Signed-off-by: Rene Scharfe
> ---
> sequencer.c | 46 +-
> 1 file changed, 17 insertions(+), 29 delet
Hello Eyjolfur,
git is a version control system, which is mostly content agnostic. It
knows nothing about json or xml, let alone how to convert them.
You might want to use some kind of programming language to do the
conversion.
Could you perhaps explain more why you are asking this question?
Kevin.
On Tue, Oct 31, 2017 at 05:33:57PM +0100, Kevin Daudt wrote:
> On Tue, Oct 31, 2017 at 10:54:21AM +0100, René Scharfe wrote:
> > Reduce code duplication by extracting a function for rewriting an
> > existing file.
> >
> > Signed-off-by: Rene Scharfe
&g
it as a BUG when the prefix argument of normalize_glob_ref starts
with a '/' so that future callers will be aware of this contract.
Signed-off-by: Kevin Daudt
---
refs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/refs.c b/refs.c
index e9ae659ae..6747981d1 100644
--- a/refs.c
+
ss, or -1 if
Is it correct to call the result binary? I would say that it's the value
that gets stored. To me, this value does not really have a base.
Kevin
On Sun, Nov 05, 2017 at 05:47:47PM +0100, René Scharfe wrote:
> Am 05.11.2017 um 03:56 schrieb Kevin Daudt:
> > On Tue, Oct 31, 2017 at 02:46:49PM +0100, René Scharfe wrote:
> >> Make the function for converting pairs of hexadecimal digits to binary
> >> av
renames turned off.
Thanks,
Kevin
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf
> Of Peter Krefting
> Sent: Friday, November 10, 2017 7:05 AM
> To: Derrick Stolee
> Cc: Jeff King ; Git Mailing List
> Subject: Re: che
On Sat, Nov 11, 2017 at 08:26:00AM -0500, Robert P. J. Day wrote:
>
> Current man page for "bisect" is inconsistent explaining the fact that
> "git bisect" takes precisely one bad commit, but one or more good
> commits, so tweak the man page in a few places to make that clear.
>
> rday
>
> Signe
it config --expiry-date date.valid2 &&
> + git config --expiry-date date.valid3 &&
> + git config --expiry-date date.valid4
> + } >actual &&
> + test_cmp expect actual &&
> + test_must_fail git config --expi
e new branch name
> exists rather than specifying that the branch trying to be renamed
> doesn't exist.
>
> [..]
>
> Note: Thanks to the strbuf API that made it possible to easily construct
> the composite error message strings!
I'm not sure this note adds a lot, since the strbuf API is not that new.
Kevin
On Mon, Nov 13, 2017 at 08:01:12AM +0530, Kaartic Sivaraam wrote:
> On Sunday 12 November 2017 11:53 PM, Kevin Daudt wrote:
> > On Thu, Nov 02, 2017 at 12:24:07PM +0530, Kaartic Sivaraam wrote:
> > > From: Kaartic Sivaraam
> > >
> > > When trying to rename an
reciated.
Hello Frank,
Could you provide a bit more information?
- What version of git are you using?
- how did you install git,
- Do you also get segfaults outside of the virtualenv?
This sounds perhaps like it's a copattibility issue with a library.
Kind regards, Kevin.
The v1.9.1 release notes don't
mention anything notes-related so I assume these issues still exist.
-Kevin Ballard
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Apr 7, 2014, at 2:33 PM, Junio C Hamano wrote:
> Kevin Ballard writes:
>
>> I’ve started using notes recently, and I have notes.rewriteRef set so that
>> when I rebase, my notes will be kept. Unfortunately, it turns out that if a
>> rebase deletes my local commit b
st that the combining character table was originally
auto-generated from UnicodeData.txt with a "uniset" tool. Presumably this?
https://github.com/depp/uniset
The fullwidth-checking code looks like it was done by hand, although
apparently uniset can process EastAsianWidth.txt.
Kevin
--
T
at is acknowledged at the top of the
file:
http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
Good, because he knows what he's doing.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
And while you're here I think it's probably worth updating the width=2
test now too, to make this a complete update to Unicode 6.3. I can see
it needs a few extensions (eg A960-A97C, FE10-FE19, 1F200-1F251).
Kevin
--
To unsubscribe from this list: send the line "unsubscribe g
ty
close to "git checkout -B ". It certainly won't lose
your workspace file, but unlike checkout it /does /forget what you've
staged, which could be annoying. Maybe that could be modified to keep
the index too?
(I like your alias.become - might try that).
Kevin
--
To unsubsc
On 01/06/2014 07:26, Atsushi Nakagawa wrote:
Kevin Bracey wrote:
The original "git reset --hard" used to be a pretty top-level command.
It was used for aborting merges in particular. But I think it now
stands out as being one of the only really dangerous porcelain
commands, and I c
ighten up the EXAMPLES section? Give it
easy-to-locate /--soft/--mixed/--keep subheadings, covering all
those common use cases (in clean trees...), including a before/after git
status views. Then normal users could skip the top technical section
waffling about indexes and go straight there in
being undone is already public.
Given those, I honestly don't think I'd ever need to explain git reset
to anyone again. Which would be nice...
(Note I propose no "--mixed" equivalent for the commit undos, but it's
easy enough to follow the "commit --undo" with
th an escape character such as
"mytag\(", it won't complete the name from that point.
This appears to be true for other bash meta characters as well such as
'<', '>', '|', ';', '&'
---
Kevin Stenerson
k
git isn’t tracking folder renames when the case of the letters change, but it
will track it if the folder changes names. Is this intentional?
Here is an example:
08:51:26 ~/test $ git init
Initialized empty Git repository in /Users/kcoleman/test/.git/
08:51:29 ~/test (master #) $ mkdir main
08:
Foo/
nothing added to commit but untracked files present (use "git add" to track)
11:42:48 ~/test (master) $ git add .
11:43:18 ~/test (master +) $ git commit -m "second"
[master f78d025] second
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 Foo/bar.md
Awesome reply! That makes sense. So basically if I accidentally capitalize a
folder name and commit it, I need to be very careful when I correct it.
Definitely ran into this problem with my repo and ‘lost’ a few commits before I
noticed something was off.
-Kevin Coleman
> On Feb 3, 2015,
ants to resume a clone (or fetch) and what parts are still missing, and
probably lots of other details I'm missing.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
;follow first treesame parent" rule
if all remaining parents are off-graph.
Does that make sense? Going to have to think harder.
I note that "gitk v1.8.3^0..v1.8.4" and "git log --parents
v1.8.3..v1.8.4" show that merge in Git 1.8.3, but not in Git 1.8.4. So
we're going partially forwards, at least.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/09/2013 01:23, Junio C Hamano wrote:
Kevin Bracey writes:
On 10/09/2013 20:19, Junio C Hamano wrote:
This command
$ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl
reports that a merge 766f0f8ef7 (which did not touch the specified
path at all) touches it.
Bisecting points at
On 11/09/2013 21:24, Jonathan Nieder wrote:
Kevin Bracey wrote:
On reflection I'm not sure what we should for the "simple history"
view of v1.8.3.1..v1.8.4. We're not rewriting parents, so we don't
get a chance to reconsider the merge as being zero-parent, and we do
ha
On Fri, Feb 20, 2015 at 10:16:18PM -0700, Technext wrote:
> Thanks Junio for the prompt reply! :) Yes, that's exactly how i would like
> things to be. I'll definitely try to push this thing and see if this flow
> can be implemented.
>
> However, can you please guide me whether there's any way i co
e set with the remote..tagopt config
option, which takes values [--tags|--no-tags].
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Currently, only the behaviour when this option is set is explained, but
it's unclear what happens when this option hasn't been set.
Signed-off-by: Kevin Daudt
---
Documentation/config.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/co
Only behaviour with these options are currently explained. Add
explanation what the default behaviour is.
Signed-off-by: Kevin Daudt
---
Documentation/git-remote.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index a77607b
On Wed, Mar 04, 2015 at 04:46:47PM +0100, Michael J Gruber wrote:
>
> So, how does this relate to:
>
> http://permalink.gmane.org/gmane.comp.version-control.git/264592
>
> I don't mind you taking this over at all, it's just that we should keep
> things together where the discussion begun.
>
> M
On Fri, Mar 06, 2015 at 02:39:58AM +, Phil Hord (hordp) wrote:
> I have a repo whose workdir tends to get pretty dirty as I jump around from
> branch to branch tending weeds and whatnot. Sometimes when I try to switch
> branches git refuses because of local file changes.
>
> git checkout
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Signed-off-by: Kevin Daudt
---
This is my first code patch, and
On Sat, Mar 07, 2015 at 10:31:16PM +0100, Kevin Daudt wrote:
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index ff84a82..c271e15 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -291,6 +291,9 @@ int cmd_rev_list(int argc, const char **argv, const
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Signed-off-by: Kevin Daudt
Suggested-by: Junio C. Hamano
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Signed-off-by: Kevin Daudt
Suggested-by: Junio C. Hamano
---
Sorry
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Signed-off-by: Kevin Daudt
Suggested-by: Junio C. Hamano
---
Sorry
On Sat, Mar 07, 2015 at 01:30:07AM +, Ken Moffat wrote:
> Hi, please CC me if that is not your usual fashion, because I am not
> subscribed.
>
> I use git for my build scripts - those are accessed over nfs. Since
> I started using 2.1 and later (I don't think I used 2.0) commands
> such as 'c
On Sun, Mar 08, 2015 at 05:58:24PM -0400, Eric Sunshine wrote:
> On Sun, Mar 8, 2015 at 11:03 AM, Kevin Daudt wrote:
> > rev-list --bisect is used by git bisect, but never together with
> > --first-parent. Because rev-list --bisect together with --first-parent
> > is not h
-by: Kevin Daudt
---
Changes since v3:
* Added an ifdef::git-rev-list[] guard around the warning in the
--first-parent section so that it only shows up in `man git-rev-list`
and not in `man git log`
* Added the warning also to the --bisect section.
Documentation/rev-list-options.txt | 4
On Tue, Mar 10, 2015 at 03:09:54PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > rev-list --bisect is used by git bisect, but never together with
> > --first-parent. Because rev-list --bisect together with --first-parent
> > is not handled currently, and
On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > git log --bisect seems to do something different then git rev-list
> > --bisect
> >
> > From git-log(1):
> >
> > Pretend as if the bad bisection ref refs/bise
Subject is usually prefixed with the part that is changed, in this case
log.
For example:
log: forbid log --graph --no-walk
On Sat, Mar 14, 2015 at 11:31:59PM +0200, epilys wrote:
> In git-log, --graph shows a graphical representation of a
> continuous commit history, and --no-walk shows discre
st, because
it found it the file actually changed in the mean time, and you broke
that promise.
But also already said, this only applies to tracked files, so not to files
that aren't being tracked in the first place.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 11, 2015 at 01:13:48PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote:
> >
>
> Step back and think why "git bisect --first-parent" is sometimes
> desired in the first pla
with these problems.
So if the Ladder logic is represented as text source, there is no
problem with it. If it'sbinary, there might be other sollutions better
suited.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vge
On Thu, Mar 19, 2015 at 07:14:52AM +, Bharat Suvarna wrote:
> Thanks all .. I will have a look. But could I just set this up on my laptop
> and checking this works on system first before installing one of Git on server
>
Sure, that's no problem. Git happily runs just locally on your own
mach
--bisect --first parent either, because refs/heads/bad is not limited to
the first parent chain.
Helped-by: Junio C. Hamano
Helped-by: Eric Sunshine
Signed-off-by: Kevin Daudt
---
Updates since v4:
* Not only refusing rev-list --bisect --first-parent, but also log --bisect
--first-parent
On Wed, Mar 18, 2015 at 02:05:09PM +0530, Sundararajan R wrote:
> The failure case which occurs on teaching git is taught the '-' shorthand
> is when there exists no branch pointed to by '@{-1}'. But, if there is a file
> named - in the working tree, the user can be unambiguously assumed to be
> r
On Fri, Mar 20, 2015 at 04:02:38AM +0530, Sundararajan R wrote:
> Yes. I made a mistake while framing the sentence. I should have proof read
> the commit message more thoroughly. Should I submit a new patch with the
> corrected commit message?
Yeah, you can combine that with the comments from Mat
On Thu, Mar 19, 2015 at 03:43:57PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > rev-list --bisect is used by git bisect, but never together with
> > --first-parent. Because rev-list --bisect together with --first-parent
> > is not handled currently, and
On Sat, Mar 21, 2015 at 02:06:33PM -0400, David A. Wheeler wrote:
> Warn cloners if there is no LICENSE* or COPYING* file that makes
> the license clear. This is a useful warning, because if there is
> no license somewhere, then local copyright laws (which forbid many uses)
> and terms of service
On Wed, Mar 25, 2015 at 11:00:21AM +0100, Christian Couder wrote:
> Hi,
>
> Git Rev News edition 1 is now available:
>
> http://git.github.io/rev_news/edition-1.html
>
> Thanks a lot to all the contributors and helpers, especially Junio!
>
> Enjoy,
> Christian and Thomas.
Thank you for your wo
t.
I guess you are aware of this, but if you want to retain more
information, you have to rely on other means, like scp to get the other
things
So to summarize, git clone is only used for cloning history, which means
objects and refs, the rest is not part of cloning. To get more, you have
to go outside git.
Hope this helps to clear some confussion.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Mar 29, 2015 at 04:21:26AM +0200, Christoph Anton Mitterer wrote:
> On Sat, 2015-03-28 at 15:31 +0100, Kevin D wrote:
> [..]
>
> > * reflog (history of refs, though, by default disabled for bare
> > repositories)
> is there a way to get this copied?
>
>
On Mon, Apr 06, 2015 at 09:27:53AM -0300, Steven Huang wrote:
> Hi,
>
> We know git uses cURL to grab https repositories from the Internet.
> Nowadays
> the SSL-enabled git repos are getting more and more, especially
> self-hosted
> ones.
>
> Some of the websites including those
On Thu, Apr 16, 2015 at 09:03:10PM +0200, Jens Lehmann wrote:
> Am 16.04.2015 um 20:09 schrieb Pedro Rodrigues:
>
> If people are interested I could try to polish it and resubmit it.
> It would be great if Pedro could test that it does what he expects.
I'm certainly interested.
--
To unsubscribe
On Mon, Apr 06, 2015 at 10:21:37PM +0800, niu2x wrote:
> I'm a beginner.
> Please tell me the log of git commit is exist forever or 90 days
As long as a commit is (indirectly) referenced by a branch or tag, it will
be kept forever. Only if you rewrite history causing commits to be
unreferenced (fo
-by: Kevin Bracey
---
Documentation/git-am.txt | 4 ++--
Documentation/user-manual.txt | 2 +-
git-am.sh | 8
t/t7512-status-help.sh| 4 ++--
wt-status.c | 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a
for "git pull --rebase". I see it run when I do "git rebase -i ...".
Is this a bug or feature? It's with git version 1.7.11.7.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/m
ignificant than I thought.
My series will also be better at optimising away D too, through a
combination of my and Junio's efforts. Try it out.
On this subject, is there any way to exclude a path from a log query? Is
there a "not" operator for paths? Might be another way of doi
s touched by commits on that
side and then skip calculating the patch ID for any commits that touch
paths outside that set. The tree comparison is a lot cheaper than doing
a diff on all of the files.
Sounds cute. Go for it :)
Kevin
--
To unsubscribe from this list: send the line "unsubsc
its is nothing compared to the fact we're already
totally omitting the non-identical ones.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13/05/2013 01:22, Junio C Hamano wrote:
Kevin Bracey writes:
git log --ancestry-path --left-right E...F --not $(git merge-base
--all E F)
which looks like we're having to repeat ourselves because it's not
paying attention...
You are half wrong; "--left-right" is a
there. And then hopefully this can proceed to next
faster.
(Dropping that commit will drop the only --ancestry-path A...B test in t6111,
meaning no immediate dependencies. But the next version of that series will be
sent with t6111 testing and expecting a pass due to this fix being in.)
Kevin
issue in
my proposed history traversal refinements series.
So ensure that the calculated merge bases are sent to add_rev_cmdline(),
flagged with new 'whence' enum value REV_CMD_MERGE_BASE.
Signed-off-by: Kevin Bracey
---
revision.c| 17 +
revision.h
Signed-off-by: Kevin Bracey
---
t/t6019-rev-list-ancestry-path.sh | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/t/t6019-rev-list-ancestry-path.sh
b/t/t6019-rev-list-ancestry-path.sh
index 39b4cb0..5287f6a 100755
--- a/t/t6019-rev-list-ancestry-path.sh
reak the linear hash collision
search. But we can remove NULL decoration entries when rebuilding the
table.
Signed-off-by: Kevin Bracey
---
decorate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/decorate.c b/decorate.c
index 2f8a63e..7cb5d29 100644
--- a/decorate.c
+
From: Junio C Hamano
Signed-off-by: Junio C Hamano
---
t/t6012-rev-list-simplify.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh
index dd6dc84..4e55872 100755
--- a/t/t6012-rev-list
hat touches
the paths we are following) are independent from each other, and
both need to be kept.
That is incorrect; when the side branch 'x' never touches the paths,
it should be removed to allow M to simplify down to the last commit
on the main history that touches the
11 failures, but creates a couple of new ones -
we are now showing some merges that don't need to be shown.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 6 +-
revision.c | 241 -
revision.h
. Merges at the boundary do not necessarily need
to be shown.
Signed-off-by: Kevin Bracey
---
revision.c | 22 +++---
t/t6111-rev-list-treesame.sh | 4 ++--
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/revision.c b/revision.c
index 1c75070..edb7e1c
l ensure alignment of the definition of
"bottom" with future patches.
Signed-off-by: Kevin Bracey
---
revision.c | 34 --
revision.h | 3 ++-
2 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/revision.c b/revision.c
index 4f7446c..6607dab 10064
lt following to test relevant_commit() instead of
!UNINTERESTING, so it can proceed straight from D to B, thus finishing
the traversal of that path.
Signed-off-by: Kevin Bracey
---
revision.c | 2 +-
t/t6111-rev-list-treesame.sh | 12 ++--
2 files changed, 7 insertions(+),
Some side branching and odd merging to illustrate various flaws in
revision list scans, particularly when limiting the list.
Many expected failures, which will be gone by the end of the "history
traversal refinements" series.
Signed-off-by: Kevin Bracey
---
t/t6111-rev-list-treesam
evision lists.
Signed-off-by: Kevin Bracey
---
revision.c| 171 +-
t/t6019-rev-list-ancestry-path.sh | 12 ++-
t/t6111-rev-list-treesame.sh | 8 +-
3 files changed, 164 insertions(+), 27 deletions(-)
diff --git a/revision.c b/rev
e followed.
This avoids producing a totally disjoint history from the default log
when the default log is a better explanation of the end result, and aids
visualisation of odd merges.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 3 +-
revision.c
In the example given, P is not TREESAME to E. This doesn't affect the
current result, but it will matter when we change behaviour.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/rev
sions.txt.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 50bbff7..55ddf33 100644
--- a/Documentation/rev-list-options.txt
+++
hecking the parents as well
t6012: update test for tweaked full-history traversal
Kevin Bracey (13):
decorate.c: compact table when growing
t6019: test file dropped in -s ours merge
t6111: new TREESAME test set
t6111: add parents to tests
rev-list-options.txt: correct TREESAME for P
From: Junio C Hamano
Signed-off-by: Junio C Hamano
---
t/t6111-rev-list-treesame.sh | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/t/t6111-rev-list-treesame.sh b/t/t6111-rev-list-treesame.sh
index b2bca77..1e4a550 100755
--- a/t/t6111-rev-lis
Signed-off-by: Kevin Bracey
---
t/t6111-rev-list-treesame.sh | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/t/t6111-rev-list-treesame.sh b/t/t6111-rev-list-treesame.sh
index 1e4a550..4d74d3c 100755
--- a/t/t6111-rev-list-treesame.sh
ESAME to 1 parent, so are treated as TREESAME and not shown. This is
clearly undesirable in the case of merge L, which dropped our G.t by
taking the non-ancestry-path version. Document this as a known failure,
and expect "H J L", the 3 merges along the path that had to chose G.t
versions.
rigin/master), and that it's
upstream is origin/topic.
So, yes, here's a vote in favour of the general concept.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 17/05/2013 22:51, Junio C Hamano wrote:
Kevin Bracey writes:
On 15/05/2013 23:34, Felipe Contreras wrote:
I think I'm using 'upstream' for something it was not intended to,
and
I think the current 'upstream' behavior should be split into
'upstream' an
at would also avoid the complaint I was about to make that putting
'current branch' in scare quotes would be annoying.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ragraph.
Signed-off-by: Kevin Bracey
---
Documentation/git-diff.txt | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index a7b4620..78d6d50 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-dif
301 - 400 of 494 matches
Mail list logo
