Not much changed in the first three patches since the edition from
last week. A clean-up to clarify the toposort API, introduction of
priority queue API, and then its use in topological sort logic.
The final patch adds log --author-date-order to build on top of
them.
Adding tests to t4202
Use the commit-queue data structure to implement a priority queue
of commits sorted by committer date, when handling --date-order.
The commit-queue structure can also be used as a simple LIFO stack,
which is a good match for --topo-order processing.
Signed-off-by: Junio C Hamano gits...@pobox.com
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted untile all children of it are. When
traversing a forked history like this with git log C E:
ABC
\
DE
we ensure that A is emitted after all of B, C, D, and E are done, B
has to
Sometimes people would want to view the commits in parallel
histories in the order of author dates, not committer dates.
Teach topo-order sort machinery to do so, using a commit-info slab
to record the author dates of each commit, and commit-queue to sort
them.
Signed-off-by: Junio C Hamano
Traditionally we used a singly linked list of commits to hold a set
of in-flight commits while traversing history. The most typical use
of the list is to add commits that are newly discovered to it, keep
the list sorted by commit timestamp, pick up the newest one from the
list, and keep digging.
Michael S. Tsirkin m...@redhat.com writes:
With respect to this, and a bit off-topic, what's
the best way to revise patch series?
What I did, given series in patchvN-1/:
rm -fr patchvN #blow away old directory if there
# otherwise I get two copies of patches if
Ramkumar Ramachandra artag...@gmail.com writes:
Do you think that the opinions of
inactive community members and non-contributors are _more_ valuable
than those of active contributors, or am I missing something?
I am not Dscho, but it probably is worth saying this anyway.
6d297f81373e
Junio C Hamano gits...@pobox.com writes:
Use the commit-queue data structure to implement a priority queue
of commits sorted by committer date, when handling --date-order.
The commit-queue structure can also be used as a simple LIFO stack,
which is a good match for --topo-order processing.
Philip Oakley philipoak...@iee.org writes:
While folks do use such simplistic names, given that the patch had
many call sites, I do think Filipe's short name would quickly become
the accepted test name and not cause any great difficulties.
OK.
--
To unsubscribe from this list: send the line
[Sorry for the full quote, but sometimes, repetita iuvant]
On 06/09/2013 11:42 PM, Michael Haggerty wrote:
On 06/09/2013 09:11 PM, Johan Herland wrote:
[...]
FWIW, I'd like to express my support for the opinions expressed by
Jonathan, Jeff and Thomas. They accurately describe my impression of
Fedore 9 shipped the gvfs package with a buggy Bash completion script:
it removed the ':' character from COMP_WORDBREAKS, thereby breaking
certain features of git's completion script. We worked this around in
db8a9ff0 (bash completion: Resolve git show ref:pathtab losing ref:
portion,
SZEDER Gábor wrote:
Fedore 9 shipped the gvfs package with a buggy Bash completion script:
it removed the ':' character from COMP_WORDBREAKS, thereby breaking
certain features of git's completion script. We worked this around in
db8a9ff0 (bash completion: Resolve git show ref:pathtab losing
On Sun, Jun 9, 2013 at 6:22 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
- strings which don't need interpolation are single-quoted for more clarity
and
slight gain of performance
- interpolation is preferred over concatenation in many cases, for more
clarity
- variables are always
On Sun, Jun 9, 2013 at 6:22 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Changes with v2:
- Remove patch [02/22] about using the Readonly module
- Split commit [07/22] into 5 different ones
This was easier to review after being split. Thanks.
- Split commit [14/22] into 2 different
On Sun, Jun 9, 2013 at 2:25 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
diff --git a/pathspec.c b/pathspec.c
index 8fe56cd..b49bd51 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -195,15 +195,128 @@ static const char *prefix_pathspec(const char *prefix,
int prefixlen, const char
+/*
+
On Mon, Jun 10, 2013 at 12:54 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
This iteration contains some minor fixups (courtesy reviews by Eric
Sunshine and Junio), and some tests from Duy squashed in.
I'm starting to think this is a half-baked solution. It hides
problems, for
I find the new atmosphere in the list uncomfortable to work with. I do
this for fun and it does not seem fun these days any more so I will
take a break from Git development. Consider all my ongoing work
abandoned. All of my public patches are signed off. If you want to
continue improve them, go
On Sun, Jun 9, 2013 at 2:25 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
diff --git a/pathspec.c b/pathspec.c
index 89bdc7f..9e68321 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -271,10 +271,20 @@ void parse_pathspec(struct pathspec *pathspec,
if (!entry !prefix)
On Sun, Jun 9, 2013 at 2:25 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
parse_pathspec: a special flag for max_depth feature
s/a/add/
match_pathspec_depth() and tree_entry_interesting() check max_depth
field in order to support git grep --max-depth. The feature
activation is tied to
On Sun, Jun 9, 2013 at 2:25 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
This flag is equivalent to builtin/ls-files.c:strip_trailing_slashes()
and is intended to replace that function when ls-files is converted to
use parse_pathspec.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
On Sun, Jun 9, 2013 at 2:25 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
This makes 'original' suitable for passing to an external command
because all pathspec magic is left in place, provided that the
external command understands pathspec. The prefixing is needed because
we usually
On Sun, Jun 9, 2013 at 2:25 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
GUARD_PATHSPEC() marks pathspec-sensitive code, basically all those
that touch anything in 'struct pathspec' except fields nr and
original. GUARD_PATHSPEC() is not supposed to fail. It's mainly to
help the designers
On Sun, Jun 9, 2013 at 7:59 PM, SZEDER Gábor sze...@ira.uka.de wrote:
Fedore 9 shipped the gvfs package with a buggy Bash completion script:
s/Fedore/Fedora/
it removed the ':' character from COMP_WORDBREAKS, thereby breaking
certain features of git's completion script. We worked this around
On Sun, Jun 9, 2013 at 7:24 PM, Junio C Hamano gits...@pobox.com wrote:
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted untile all children of it are. When
s/untile/until/
traversing a forked history like this with git log C E:
ABC
On Sun, Jun 09, 2013 at 04:24:34PM -0700, Junio C Hamano wrote:
The name lifo, however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values:
On Sun, Jun 9, 2013 at 4:42 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
Felipe, I wish that you would devote a small fraction of your prodigious
energy to the very difficult challenge of feeling empathy,
I do feel empathy, the problem is that you make the assumption that
other people are
On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
I do accuse Felipe's *attitude* to bring on and nourish such
unpleasantness toxicity. His technical merits and the possible
qualities of his patches do *nothing* to remove or quell such
issues.
How
Ignore this patch. I was using this to test and improve 'git rebase', and I was
using the lessons learned to improve 'git rebase' shell script.
I was planning it to clean it even more, and simplify it using tricks specific
to Ruby.
But no more.
There's no point in trying to improve 'git
On Sun, Jun 09, 2013 at 04:24:35PM -0700, Junio C Hamano wrote:
Traditionally we used a singly linked list of commits to hold a set
of in-flight commits while traversing history. The most typical use
of the list is to add commits that are newly discovered to it, keep
the list sorted by
On Sun, Jun 09, 2013 at 04:37:27PM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Use the commit-queue data structure to implement a priority queue
of commits sorted by committer date, when handling --date-order.
The commit-queue structure can also be used as a
Am 6/9/2013 22:31, schrieb Junio C Hamano:
Jeff King p...@peff.net writes:
I'm a little negative on handling just SIGTERM. That would make the test
pass, but does it really address the overall issue? To me, the
usefulness is having exit values with consistent meanings.
Yes. Unless the
From: Erik Faye-Lund kusmab...@gmail.com
Returning the SIGALRM handler for SIGINT is not very useful.
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Am 6/7/2013 16:20, schrieb Erik Faye-Lund:
On Fri, Jun 7, 2013 at 3:07 PM, Johannes Sixt
On Sun, Jun 09, 2013 at 04:24:37PM -0700, Junio C Hamano wrote:
Sometimes people would want to view the commits in parallel
histories in the order of author dates, not committer dates.
Teach topo-order sort machinery to do so, using a commit-info slab
to record the author dates of each
301 - 333 of 333 matches
Mail list logo
