sites
that could be converted to `xfopen` to die gracefully upon error, and
one unchecked `fdopen` that can likewise be `xfdopen`.
-Jon
On 8/29/19 4:48 PM, Eric Sunshine wrote:
On Thu, Aug 29, 2019 at 7:12 PM Jon Simons wrote:
On 8/29/19 3:45 PM, Eric Sunshine wrote:
On Thu, Aug 29, 2019 at 6:38 PM Jon Simons wrote:
+ test_write_lines /* >sparse-src/all-files &&
Hmm, does this work correctly? I would
n earlier failure to resolve it,
and when an OID resolves but parsing the sparse filter spec fails.
t5616 is updated to demonstrate the change.
Co-authored-by: Jeff King
Signed-off-by: Jeff King
Signed-off-by: Jon Simons
---
list-objects-filter.c| 6 +-
t/t5616-partial-clone.sh | 7
s a future direction.
t5616 is updated to demonstrate the change.
Signed-off-by: Jon Simons
---
list-objects-filter-options.c | 3 ++-
t/t5616-partial-clone.sh | 21 +
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/list-objects-filter-options.c b/list-obje
Included here are two fixes for partial cloning with sparse filters.
These issues were uncovered in early testing internally at GitHub,
where Taylor and Peff have provided early offlist review feedback.
This third revision includes a fix for a test bug introduced in the
second revision.
Jon
On 8/29/19 3:45 PM, Eric Sunshine wrote:
On Thu, Aug 29, 2019 at 6:38 PM Jon Simons wrote:
Fix a bug in partial cloning with sparse filters by ensuring to check
for 'have_git_dir' before attempting to resolve the sparse filter OID.
[...]
Signed-off-by: Jon Simons
---
diff --git
n earlier failure to resolve it,
and when an OID resolves but parsing the sparse filter spec fails.
t5616 is updated to demonstrate the change.
Co-authored-by: Jeff King
Signed-off-by: Jeff King
Signed-off-by: Jon Simons
---
list-objects-filter.c| 6 +-
t/t5616-partial-clone.sh | 7
f the test details: fixes, whitespace adjustment,
and some further simplifications -- thanks!
Jon Simons (2):
list-objects-filter: only parse sparse OID when 'have_git_dir'
list-objects-filter: handle unresolved sparse filter OID
list-objects-filter-options.c | 3 ++-
list-objects-f
s a future direction.
t5616 is updated to demonstrate the change.
Signed-off-by: Jon Simons
---
list-objects-filter-options.c | 3 ++-
t/t5616-partial-clone.sh | 21 +
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/list-objects-filter-options.c b/list-obje
Included here are two fixes for partial cloning with sparse filters.
These issues were uncovered in early testing internally at GitHub,
where Taylor and Peff have provided early offlist review feedback.
Jon Simons (2):
list-objects-filter: only parse sparse OID when 'have_git_dir&#x
s a future direction.
t5616 is updated to demonstrate the change.
Signed-off-by: Jon Simons
---
list-objects-filter-options.c | 3 ++-
t/t5616-partial-clone.sh | 23 +++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/list-objects-filter-options.c b/list-obje
n earlier failure to resolve it,
and when an OID resolves but parsing the sparse filter spec fails.
t5616 is updated to demonstrate the change.
Co-authored-by: Jeff King
Signed-off-by: Jeff King
Signed-off-by: Jon Simons
---
list-objects-filter.c| 6 +-
t/t5616-partial-clone.sh | 7
<<< No Message Collected >>>
tive book's version.
I agree, and I don't know what to do about that.
Jon
ly in the early chapters, I suggest giving my version a try.
Since I'm giving away my version, you have nothing to loose except
perhaps a little time. If I'm right, and my version is clearer, then
you could benefit from it.
(You're a git expert so I doubt you need my version).
Cordially,
Jon Forrest
anges I've made, it's unlikely
that my changes would be accepted.
I do track the changes to the second edition of Pro Git and
incorporate that ones that still apply into my version.
But I hear what you're saying. Maybe if and when the third edition
of Pro Git comes out I'll tr
wrote. I hope you enjoy it.
The PDF of my version is at
https://drive.google.com/file/d/18wGebSU0dyYU1L_bfyoDQtZRF1Vo1H3p/view?usp=sharing
If there's enough interest, I'll try to put up an HTML version of
the book.
Cordially,
Jon Forrest
From: Jeff King
The packet_read_line() function dies if it gets an
unexpected EOF. It only returns NULL if we get a flush
packet (or technically, a zero-length "0004" packet, but
nobody is supposed to send those, and they are
indistinguishable from a flush in this interface).
Let's correct error
error rather than segfault.
Signed-off-by: Jon Simons
---
remote-curl.c | 2 ++
send-pack.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/remote-curl.c b/remote-curl.c
index 0053b09..9903077 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -339,6 +339,8 @@ static struct discovery
Included here are a couple of fixes and cleanups for
handling NULL return values from 'packet_read_line'.
Jeff King (1):
correct error messages for NULL packet_read_line()
Jon Simons (1):
always check for NULL return from packet_read_line()
builtin/archive.c | 2 +-
fetch-pack.
So, like, Junio C Hamano said:
> There are two topics that are marked as "Will cook in 'next'" for
> practically forever in the "What's cooking" reports. The world may
> have become ready for one or both of them, in which case we should
> do the merge not too late in the cycle.
>
> * jc/merge-dro
So, like, Prathamesh Chavan said:
> The exit code of the upstream of a pipe is ignored thus we should avoid
> using it. By writing out the output of the git command to a file, we
> can test the exit codes of both the commands.
>
> Signed-off-by: Prathamesh
> ---
> t/t2027-worktree-list.sh | 14 +
So, like, Junio C Hamano said:
> Stefan Beller writes:
>
> > Do we want to invent a special value for url.*.insteadOf to mean
> > "look up in superproject, so I don't have to keep
> > a copy that may get stale" ?
>
> My gut feeling is that we should do the selective/filtered include
> Peff m
So, like, Junio C Hamano said:
> Matt McCutchen writes:
>
> > Then the server generates a commit X3 that lists Y2 as a parent, even
> > though it doesn't have Y2, and advances 'x' to X3. The victim fetches
> > 'x':
> >
> >victim server
> >
> > Y1---Y2---
So, like, David Bainbridge said:
> Hi,
>
> The subject matter of the conference looks really interesting but I am
> unlikely to be able to attend, unfortunately.
>
> The subjects being covered like the current State of Git and the
> Future of Git, for example, deserve much wider exposure, and I w
So, like, Jeff King said:
> On Tue, Sep 06, 2016 at 12:42:04PM -0500, Jon Loeliger wrote:
>
> > I have recently been enlisted by folks at the Linux Foundation to
> > help run a Miniconference on Git at the Plumbers Conference [*]
> > this fall.
>
> I see the confer
Folks,
I have recently been enlisted by folks at the Linux Foundation to
help run a Miniconference on Git at the Plumbers Conference [*]
this fall.
We currently have both Junio Hamano and Josh Triplett signed
up to do talks. Hopefully, though not confirmed yet, Junio
will give us a brief "State
t, is to keep the same coverage
as upstream.
If they add something about Gitolite to their next edition, then
I will also.
Cordially,
Jon Forrest
--
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
hanks for the report. I guess for now the best thing to do is
to use the HTML version.
Jon
--
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
in
different commit IDs each time.
Case closed.
Thanks, Jakub!
Jon Forrest
--
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
hallucinating, this will be a
great way to update both the pdf and the HTML versions as
they change in the future.
Jon
--
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
ases do you want/need the commit ids to be equal?
Can you be more specific?
Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd
Edition (or just Pro Git 2nd Edition - it doesn't matter). You see
lots of output showing 'git commit' commands and the commit IDs th
of Git for little benefit
(see the beginning of reply for alternate solutions).
Even using your environment variable solution that wouldn't
require any code changes?
Jon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.
ges there (like the one I posted
as demo:
https://github.com/nobozo/progit2/commit/43ae203c2ccf1a017153de1b41a8c47eb166dba1#commitcomment-18372006
That would be great. I think I'm setup for that now in my GitHub
repo for that book.
Jon
--
To unsubscribe from this list: send the line "unsu
r instructional purposes only, and only when the committer
explicitly
chooses to use this option. I'm *not* proposing a general change to Git's
behavior.
Is such a thing to ridiculous to even consider? Is there a better way to
achieve the same result?
Jon Forrest
--
To unsubscribe
ary of those changes?
There are too many to summarize. Some are of the type that the proofreader
should have caught, and others are my attempt to clarify things. Since I
don't claim to be a Git expert it remains to be seen how successful I am.
Jon
--
To unsubscribe from this list: send the
hhMm8
The complete self-contained HTML is at:
https://drive.google.com/file/d/0B-Llso12P94-U3g1aDBRWjk1Sk0
The sources for this book are at:
https://github.com/nobozo/progit2
I welcome comments.
Jon Forrest
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
when the same repo is shared
by both Windows and *nix Git users over Dropbox or a shared filesystem?
Jon Forrest
--
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
Windows.
Thanks for the quick (and correct) response.
Jon Forrest
--
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 5/20/2016 6:19 AM, Torsten Bögershausen wrote:
On 20.05.16 03:48, Jon Forrest wrote:
I'm running Git version 2.8.2 built from source on Ubuntu 16.04.
I'm using a repository that's stored on Dropbox. I'm the only person
accessing this repo. Everything works great.
For
epo to a non-Dropbox location, just in case
it was Dropbox that was causing the problem, but this didn't
make any difference.
(If you want to try this yourself, try it on the ProGit2
book source on Github).
Thanks,
Jon Forrest
--
To unsubscribe from this list: send the line "unsubscr
Hello,
tl;dr: Can I get Git/SVN working on my MacBook if there are external references
in the repository? If not, are there alternatives that I can leverage?
I'm trying to use git svn to clone a repository that contains externals. On my
Windows7 machine it works perfectly. On my Mac (running OSX
nch onto the tip of master
branch and then repeat the cycle again. There is some risk of history
loss with this approach - a later release of the client branch may not
be a direct descendent of an earlier release of the client branch, but
even this problem can be solved with judicious use of merg
https://www.dropbox.com/s/4awq55350ef235m/progitreedited.en.pdf
and the source code is at
https://github.com/nobozo/progitreedited
I welcome your feedback. Please send any comments to me at
nob...@gmail.com. To make sure I recognize them as
comments about this book, please include [PGR] in the
subject.
Jon Forres
My experience is that the fetch will be atomic - it either fetches an
SVN commit or it doesn't.
Failure during dcommit is more painful and I usually find it is
necessary to manually use a git rebase to rebase the commits that
didn't make it to SVN on top of the commits that did.
jo
I have seen this behaviour, though never determined the root cause
.Probably the simplest thing you can do without access to the server
is to put your git svn fetch into a bash while loop, like so:
while ! git svn fetch; do :; done;
jon
On Sat, Nov 30, 2013 at 10:14 AM, Matěj Cepl wrote:
>
>From the perspective of topic there had been no change to the
definition of bar(), hence there was no change to contribute to the
eventual merge with master.
One way to avoid this kind of problem is to avoid making (or
cherry-picking) the same change on different branches, but instead use
a merge
> Thomas Ackermann writes:
>
> > Sorry Jon, but this might not be of any help to new Git users ;)
> >
> > Signed-off-by: Thomas Ackermann
>
> Yeah, I think this is long overdue. The drawing was taken from an
> e-mail posted in a discussion, and the credi
g oddly self-referential about this quip
being removed from the document. Perhaps we should notify
the Boy from "Paradise By The Dashboard Light" that he
can rest easily now without the Girl as it seems the
end of time has come at last.
Acked-by: Jon Loeliger
jdl
--
To
oblem that sometimes
occurs when git-svn pulls merges back from SVN.
jon.
On Wed, Jul 31, 2013 at 8:14 PM, Jon Seymour wrote:
> I am getting some unexpected results from a merge and I'd like to
> understand why.
>
> I have two commits X and Y that I want to merge.
>
> git merge-b
repo that does have some 4+ parent merges in it.
jon.
--
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
Ah, answering my own question
I can see git svn reset does exactly what I need.
jon.
On Mon, Mar 18, 2013 at 4:03 PM, Jon Seymour wrote:
> G'day,
>
> I managed to lose sync between the git-svn repo that I am using to
> track an svn repo. In particular, the git-svn repo lo
On Fri, Sep 28, 2012 at 2:58 PM, Jon Seymour wrote:
> G'day
>
> An svn developer created a branch from a subdirectory of the trunk
> rather than by copying trunk itself.
>
> I want to avoid pulling this branch into my git repo with git svn
> fetch because the re-rooting
On Mon, 2005-08-29 at 10:03, Linus Torvalds wrote:
> (Both "git branch" and "git checkout -b " that reate a new
This of course, is Git's answer to the long standing
UNIX tradition. Whereas UNIX would creat() files,
Git will reate() branches.
> Linus
jdl
-
To uns
G'day Junio,
>
> Jon, do we really need bignum to do the flow computation? From
> a quick glance, it appears to me that the fraction manipulation
> part is quite well isolated. Do you think adding the support
> for using other bignum implementation be reasonable (assuming
Hi GITers,
So, after you dink around in a GIT tree for a while,
and you discover little bloblets left around by using
git-fsck-cache, what do you do? How can you clean up
afterwards?
Specifically, I have a GIT tree that shows some dangling
blobs that are unreferenced in my tree. Not sure how th
object = tag->tagged;
> + object = parse_object(tag->tagged->sha1);
> }
>
> /*
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo
39bf6003cc3188a10426b62d8c47ab40
[EMAIL PROTECTED] linus]$
--
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ack - sorry I didn't notice that side effect.
jon.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ok, you asked for it:
...the GIT bucket.
jon.
... ducks for cover ...
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ins a big fix, but assumes the tidy ups above have
been applied:
[PATCH 1/2] Fix --topo-order, --max-age interaction issue
[PATCH 2/2] Add test case that shows --topo-order, --max-age break
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
-
To unsubscribe
> This series contains a big fix, but assumes the tidy ups above have
> been applied:
That'd be a _bug_ fix
jon.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Applied the --merge-order, --max-age fix to fix
the --topo-order problem demonstrated by the test
case in the previous patch.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
rev-list.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
8238686fd422959dae50a908b3761aa545be1c4
Uncommented a test case that shows a --topo-order, --max-age break.
A subsequent patch witll fix this defect
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
t/t6003-rev-list-topo-order.sh | 20 ++--
1 files changed, 10 insertions(+), 10 del
Since --merge-order is the only thing that cares about the rev-list
parse order, change the rev-list list to match the parse order
and remove the corresponding compensating reversal from epoch.c.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
[PATCH] Move SEEN flag into epoch.h, repla
one and, for completeness,
BOUNDARY and DISCONTINUITY too.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
epoch.c| 14 --
epoch.h|4 +---
rev-list.c |5 ++---
3 files changed, 11 insertions(+), 12 deletions(-)
54a391ba7e4f96ce08ecb7da82941519b8a14c30
diff
Now that duplicates are elided early, there is no need for the
SHOWN flag.
This patch removes the SHOWN flag and its uses from rev-list.c
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
rev-list.c |4 +---
1 files changed, 1 insertions(+), 3 del
This change ensures that git-rev-list --merge-order produces the same result
irrespective of what position the --merge-order argument appears in the argument
list.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
Linus: if you'd prefer to fix this a different way, that's fine
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
Linus: the last test fails with --topo-order at the moment. I haven't
seen your most recent changes, so it may still fail for trivial
reasons even then. If so, I'll post an update.
t/t6003-rev-list-topo
.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
t/t6000-lib.sh | 12 +++-
t/t6001-rev-list-merge-order.sh |9 -
t/t6002-rev-list-bisect.sh | 10 --
t/t6003-rev-list-topo-order.sh |9 -
4 files changed, 7 insertions(+), 33 del
This invariant is weaker than the --merge-order invariant, but is cheaper
to calculate (assuming the list has been identified) and will serve any
purpose where only a minimal topological order guarantee is required.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
Note: this patch currently has n
Swap the order of insert_by_date arguments so that it
matches the order of commit_list_insert.
This patch anticipates a future change which will call the
function via a pointer.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
commit.c |8
commit.h |6 +-
e
This patch adds a hacky special case to the rev-list main to restore the order
in which
the --merge-order sort algorithm receives arguments.
A subsequent patch will abstract this out more cleanly.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
rev-list.c |5 -
1 files chan
code.
This change also makes --show-breaks imply --merge-order rather than require
it as before. There was no advantage to the previous strict argument
checking.
A subsequent change will take advantage of this pattern to introduce a
topological sort switch.
Signed-off-by: Jon Seymour <[EM
I have re-issued the patches I have created in the last day after checking
that they apply correctly when applied in this order to the
current Linus HEAD (b43d44779bf98977b211256f936d0edda8a9625a)
Introduction of --topo-order and tidy up of rev-list.c
[PATCH 1/13] Temporary fixup to rev-list.c t
--merge-order can be maintained.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
Paul, could you review this patch and if you agree, ack it.
The rationale for changing gitk to use --topo-order is that git-rev-list will
produce the same order for --topo-order irrespective of the order of the
This patch introduces a --topo-order switch to git-rev-list.
When this --switch is specified, a minimal topological sort
weaker than the --merge-order sort is applied to the output
list.
The invariant of the resulting list is:
a is reachable from b => ord(b) < ord(a)
Signed-off-b
This patch introduces some unit tests for the git-rev-list --bisect
functionality.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
t/t6002-rev-list-bisect.sh | 247
1 files changed, 247 insertions(+), 0 deletions(-)
create mode 100755 t
git-rev-list --topo-order HEAD HEAD
caused a segmentation violation.
This has now been fixed.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
commit.c | 15 +++
commit.h |3 +++
epoch.h| 13 ++---
rev-list.c |8
4 files chang
This patch implements a small tidy up of rev-list.c to reduce
(but not eliminate) the amount of ugliness associated
with the merge_order flag.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
Linus: I decided not to abstract this out as a function
as _too_ much abstraction can be a bad
This trivial patch removes the semicolon as the sed seperator in the
t/t6000-lib.sh test script
and replaces it with white space. This makes BSD sed(1) much happier.
Signed-off-by: Mark Allen <[EMAIL PROTECTED]>
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
I've applied
This patch passes the test case introduced by the previous patch.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
epoch.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
6f7f90901ec4aafd12ac4179110b78fc426395cd
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/e
This test case demonstrates a problem with --merge-order.
A
|
B
|\
C D
|/
E
|
F
git-rev-list --merge-order A B doesn't produce the expected output of
A
B
D
C
E
F
The problem is fixed by a subsequent patch.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
t/t6001-rev-list-mer
Functions that are useful to other t6xxx testcases are moved into t6000-lib.sh
To use these functions in a test case, use a test-case pre-amble like:
. ./test-lib.sh
. ../t6000-lib.sh # t6xxx specific functions
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
t/t6000-
This test case demonstrates a problem with --merge-order.
A
|
B
|\
C D
|/
E
|
F
git-rev-list --merge-order A B doesn't produce the expected output of
A
B
D
C
E
F
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
This patch is known designed to apply on top of:
[PATCH 1/6] Tempora
This patch passes the test case in the first patch of this series.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
epoch.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
e4f793b932b30a7bee16610e311630515fe88330
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/e
This trivial patch removes the semicolon as the sed seperator in the
t/t6000-lib.sh test script
and replaces it with white space. This makes BSD sed(1) much happier.
Signed-off-by: Mark Allen <[EMAIL PROTECTED]>
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
I've applied
This patch introduces some unit tests for the git-rev-list --bisect
functionality.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
t/t6002-rev-list-bisect.sh | 247
1 files changed, 247 insertions(+), 0 deletions(-)
create mode 100755 t
Functions that are useful to other t6xxx testcases are moved into t6000-lib.sh
To use these functions in a test case, use a test-case pre-amble like:
. ./test-lib.sh
. ../t6000-lib.sh # t6xxx specific functions
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
This patch series intr
This patch implements a small tidy up of rev-list.c to reduce
(but not eliminate) the amount of ugliness associated
with the merge_order flag.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
Linus: I decided not to abstract this out as a function
as _too_ much abstraction can be a bad
code.
This change also makes --show-breaks imply --merge-order rather than require
it as before. There was no advantage to the previous strict argument
checking.
A subsequent change will take advantage of this pattern to introduce a
topological sort switch.
Signed-off-by: Jon Seymour <[EM
Swap the order of insert_by_date arguments so that it
matches the order of commit_list_insert.
This patch anticipates a future change which will call the
function via a pointer.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
commit.c |8
commit.h |6 +-
e
This patch adds a hacky special case to the rev-list main to restore the order
in which
the --merge-order sort algorithm receives arguments.
A subsequent patch will abstract this out more cleanly.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
rev-list.c |5 -
1 files chan
This invariant is weaker than the --merge-order invariant, but is cheaper
to calculate (assuming the list has been identified) and will serve any
purpose where only a minimal topological order guarantee is required.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
Note: this patch currently has n
--merge-order can be maintained.
Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---
Paul, could you review this patch and if you agree, ack it.
The rationale for changing gitk to use --topo-order is that git-rev-list will
produce the same order for --topo-order irrespective of the order of the
This patch introduces a --topo-order switch to git-rev-list.
When this --switch is specified, a minimal topological sort
weaker than the --merge-order sort is applied to the output
list.
The invariant of the resulting list is:
a is reachable from b => ord(b) < ord(a)
Signed-off-b
G'day Linus,
Is there some reason why this didn't get applied?
jon.
On 7/5/05, Jon Seymour <[EMAIL PROTECTED]> wrote:
>
> A recent change to rev-list altered the order in which start points
> are presented to the merge-order sort algorithm. This caused
> brea
is not clear to me git-format-patch-script needs to worry about
merge questions. It'd be better to put such logic in a separate
rebasing script, I think. If anything, you might want to add checks to
git-format-patch script that refuse to generate a patch sequence for
any sequence of pat
t
> to the gloomy dark world of the poor core Git plumbing users. ;-)
As one who inhabits that dark world, I second that!
jon.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I ack the patch, though --show-breaks could use the same treatment.
jon.
On 7/5/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> The --merge-order flag does not take parameter so there is no
> point doing strncmp with the length.
>
> Signed-off-by: Junio C Hamano
1 - 100 of 111 matches
Mail list logo
