Re: Workflow on git with 2 branch with specifc code

[Jon Seymour]

On Sat, Jan 18, 2014 at 10:05 AM, brian m. carlson
 wrote:
> On Fri, Jan 17, 2014 at 10:14:28AM -0200, Gordon Freeman wrote:
>> Hello guys, im Gordon.
>>
>> I have a question about workflow with git that i dont know if im doing
>> it right.
>> I have 1 repo with 2 branchs the first is the master of the project.
>> the second is a branch copy of the master but he need to have some
>> specifc code because is code for a client.
>> so, every time that i updade master i need to merge master with client
>> branch and it give me conflicts of course that will hapen.
>> Well if was just me who work on this 2 branchs it will be easy to fix
>> the conflicts and let all work and shine.
>> But whe have here, 10 people woking on master branch and some times code
>> are lost on merge and we need to look on commits to search whats goin
>> on.
>> What i just asking here is if its correct the workflow that i do. If for
>> some problem like this, the community have a standard resolution. Or if
>> what im doing here is all wrong.
>
> There are many correct workflows.  I personally use the workflow you've
> mentioned for the exact same reason (customizations for a client), but
> I'm the only developer on that repository.
>

I agree with Brian that there are many correct workflows and which one
you choose does depend on details of the branches you are trying to
manage.

Myself, I would tend to avoid a workflow in which you continually
merge from master into the client branch. The reason is that once you
have done this 20 times or so it will become quite difficult to
understand how and why the client branch diverged from the master
branch. Yes, it is in the history, but reasoning about diffs that
cross merge points is just hard.

Assuming that there is not much actual development on the client
branch, but rather a relatively small set of customizations to
configuration and things of that kind, then I would tend to maintain
the client changes as topic branch, then maintain a client integration
branch which represents the merge between master and the client topic
branch. Changes that represent divergence of the client from the
master branch would be committed to the client topic branch and then
merged into the client integration branch.  Refreshes from master
would be merged into the integration branch. Commits directly to the
integration branch would be avoided where possible.

Once master has diverged from client enough that there start to be
frequent conflicts when merging into the integration branch, then
consider rebasing the client topic branch 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 merge -s ours
after you have successfully rebased the client topic branch. I can
expand on how you do this, if there is interest.

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

Re: git-svn troubles with calendarserver SVN repo

[Jon Seymour]

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.

jon.

On Mon, Dec 2, 2013 at 5:03 PM, Matěj Cepl  wrote:
> On 30/11/13 09:54, Jon Seymour wrote:
>> 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;
>
> Of course, I did this, but still I wonder how much is the resulting git
> repository http://luther.ceplovi.cz/git/CalendarServer.git/ faithful
> representation of the original SVN one http://trac.calendarserver.org/.
> Would not be something missing?
>
> Best,
>
> Matěj
>
> --
> http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
> GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
>
> They that can give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety.
> -- Benjamin Franklin, Historical Review
>of Pennsylvania, 1759.
>
--
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

Re: git-svn troubles with calendarserver SVN repo

[Jon Seymour]

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:
> Hi,
>
>
>
> I am trying to git-svn clone
> https://svn.calendarserver.org/repository/calendarserver/CalendarServer/
> and I cannot say I am much succesful. Every couple of hundred of commits
> I get this:
>
>
> RA layer request failed: REPORT of
> '/repository/calendarserver/!svn/vcc/default': could not connect to
> server (https://svn.calendarserver.org) at
> /usr/local/share/perl5/Git/SVN/Ra.pm line 290.
>
>
> and git-svn stops. When restarting git svn fetch, it fetches
> another couple of hundred commits and then fails again. Given
> that there are 11000+ commits just in the trunk, I am afraid of
> a long long night. Did anybody managed to clone this repo? Or is
> there some way how to make git-svn more patient (this error
> means the SVN server is a bit flakey, right)?
>
> Best,
>
> Matěj
> --
> http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
> GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
>
> A day without sunshine is like night.
>
--
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

Re: Git merge: conflict is expected, but not detected

[Jon Seymour]

>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 of a branch with a common base to implement changes needed on
multiple branches.

So, assuming you recognized the need to delete bar() from both topic
and master, create a new branch from the merge-base of topic and
master and delete bar() in that branch. Then merge this branch into
both topic and master.

If you subsequently decide to revert the removal of bar() on topic
then when you decide to merge topic back into master, git will see
that the removal branch has been merged into both branches and will
see the subsequent revert on topic as a change that needs to be merged
and you will get the result you are looking for.

So, as a general rule of thumb, try to avoid making the same change on
two different branches and instead factor out a change needed in
multiple places into a separate branch which is then merged into the
branches that need iit.


On Sat, Nov 30, 2013 at 1:26 AM, Evgeniy Ivanov  wrote:
> Hi!
>
> Let's say I have two identical branches: master and topic. In master I
> remove some code, i.e. function bar(). In topic I do the same (commit)
> and after some time I realize I need bar() and revert previous commit
> with removal.
> So I end with master with no bar() and topic with bar() in its
> original state. When I merge I get code without bar() and no merge
> conflict (recursive or resolve strategies). Is it possible to detect
> such situations as conflicts? When bar() is C++ virtual there is no
> possibility to catch this with compiler.
>
> Please, CC me since I'm not subscribed.
>
> Thanks in advance!
>
> --
> Cheers,
> Evgeniy
> --
> 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
--
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

Re: Unexpected merge results in git-svn repo

[Jon Seymour]

To answer my own question...

My issue turned to be caused by a bad graft in my repo (unfortunately,
since hardened with filter-branch) that was making the commit that
modified F on Y reachable from X. The graft was an (incorrectly
executed) attempt to deal with the "3+ parent" problem 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-base X Y # yields B
> git diff B X -- F  # is empty
> git diff B Y -- F  # contains the change I want merged
> git rev-list X ^B -- F # is empty
> git rev-list Y ^B -- F # contains one commit
>
> git checkout X
> git merge Y
>
> fails with fixable merge conflicts on other files, but uses X's copy
> of F instead of Y's.
>
> I was expecting it to use Y's copy of F, since only Y has modified F since B.
>
> What could cause this?
>
> BTW: I am using a git-svn 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

Unexpected merge results in git-svn repo

[Jon Seymour]

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-base X Y # yields B
git diff B X -- F  # is empty
git diff B Y -- F  # contains the change I want merged
git rev-list X ^B -- F # is empty
git rev-list Y ^B -- F # contains one commit

git checkout X
git merge Y

fails with fixable merge conflicts on other files, but uses X's copy
of F instead of Y's.

I was expecting it to use Y's copy of F, since only Y has modified F since B.

What could cause this?

BTW: I am using a git-svn 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

Re: Recovering from a loss of sync between git and svn

[Jon Seymour]

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 lost the content of
> about 5 commits with the net result that the git-svn repo and the svn
> repo it tracks have a difference of opinion about what the contents of
> trunk are for the files involved in the missing commits.
>
> The situation arose because I used --ignore-paths trunk on a
> git-svn-fetch when I was trying to deal with an SVN user that had
> copied trunk into the same SVN tag twice (which caused the source tree
> to be duplicated under the trunk directory of the SVN tag).
>
> I was hoping that --ignore-paths trunk would cause the git-svn copy of
> the tag to exclude the unwanted copy of the trunk directory in the
> tag. Instead, it appears to have caused my fetches of subsequent
> commits to SVN trunk to be empty, resulting in divergence between by
> git-svn repo and the SVN repo itself.
>
> Does anyone have any tips about how I can fix this other than pulling
> the entire SVN repo again?
>
> 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

Re: Stopping git-svn pulling a particular branch

[Jon Seymour]

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 pulls in too much history and content
> that I don't want.
>
> Is there any easy way to achieve this? I tried used the --ignore-paths
> option, but this doesn't seem suited to the purpose.
>
> I can delete the SVN branch if that will help, but past experience
> suggests that it won't.
>

Answering my own question. There is an undocumented option to git-svn
--ignore-refs which can be used to achieve this.

I found that I had to manually delete the directories corresponding to
the bogus branches from .git/svn/refs/remotes, then re-run git svn
fetch with the --ignore-refs option set to a regex that matched the
bogus branches.

This allowed me to fetch everything else I needed to fetch and
advanced the maxRevs metadata in .git/svn/.metadata past the
problematic  branches so that subsequent svn fetch calls avoided the
attempts to fetch the bogus branches.

I'll draft a documentation patch when I get a chance...

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

Re: [PATCH] Under NO_OPENSSL -lssl should not be used

[Jon Seymour]

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
> you do need to use bignum based fraction)?
>

Sorry, only just saw this. An alternative bignum implementation would
be ok, I just used the ssl stuff since it happened to do what I want
and was available. I also have a patch in the pipes that gets around
the need for arbitrary precision fractions completely.

jon.

> 
> This is quick and dirty but under NO_OPENSSL we should not
> attempt to link with -lssl (nor -lcrypto).
> 
> Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
> ---
> cd /opt/packrat/playpen/public/in-place/git/git.junio/
> jit-diff
> # - pu: Fetch from a packed repository on dumb servers.
> # + (working tree)
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -108,9 +108,11 @@ LIBS += -lz
> 
>  ifndef NO_OPENSSL
> LIB_OBJS += epoch.o
> +   OPENSSL_LIBSSL=-lssl
>  else
> CFLAGS += '-DNO_OPENSSL'
> MOZILLA_SHA1=1
> +   OPENSSL_LIBSSL=
>  endif
>  ifdef MOZILLA_SHA1
>SHA1_HEADER="mozilla-sha1/sha1.h"
> @@ -148,7 +150,7 @@ git-ssh-pull: rsh.o pull.o
>  git-ssh-push: rsh.o
> 
>  git-http-pull: LIBS += -lcurl
> -git-rev-list: LIBS += -lssl
> +git-rev-list: LIBS += $(OPENSSL_LIBSSL)
> 
>  $(LIB_OBJS): $(LIB_H)
>  $(DIFF_OBJS): diffcore.h
> 
> Compilation finished at Fri Jul 29 21:48:01
> 
> 


-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
-
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

Re: [PATCH] Dereference tag repeatedly until we get a non-tag.

[Jon Seymour]

This seems reasonable to me. I have thought this would be useful on
several occasions and haven't yet conceived of a counterexample where
it would break something.

On 7/11/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> When we allow a tag object in place of a commit object, we only
> dereferenced the given tag once, which causes a tag that points
> at a tag that points at a commit to be rejected.  Instead,
> dereference tag repeatedly until we get a non-tag.
> 
> This patch makes change to two functions:
> 
>  - commit.c::lookup_commit_reference() is used by merge-base,
>rev-tree and rev-parse to convert user supplied SHA1 to that of
>a commit.
>  - rev-list uses its own get_commit_reference() to do the same.
> 
> Dereferencing tags this way helps both of these uses.
> 
> Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
> ---
> 
> *** Whether having a tag pointing at another tag is a separate
> *** issue, but I do not see a reason to forbid it.  Maybe it
> *** is used to represent a chain of trust.
> 
>  commit.c   |5 +++--
>  rev-list.c |4 ++--
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> 0dc9377363ee73c5e3f3711d6f82e49886ce8c6a
> diff --git a/commit.c b/commit.c
> --- a/commit.c
> +++ b/commit.c
> @@ -52,8 +52,9 @@ struct commit *lookup_commit_reference(c
> 
> if (!obj)
> return NULL;
> -   if (obj->type == tag_type)
> -   obj = ((struct tag *)obj)->tagged;
> +   while (obj->type == tag_type)
> +   obj = parse_object(((struct tag *)obj)->tagged->sha1);
> +
> return check_commit(obj, sha1);
>  }
> 
> diff --git a/rev-list.c b/rev-list.c
> --- a/rev-list.c
> +++ b/rev-list.c
> @@ -367,12 +367,12 @@ static struct commit *get_commit_referen
> /*
>  * Tag object? Look what it points to..
>  */
> -   if (object->type == tag_type) {
> +   while (object->type == tag_type) {
> struct tag *tag = (struct tag *) object;
> object->flags |= flags;
> if (tag_objects && !(object->flags & UNINTERESTING))
> add_pending_object(object, tag->tag);
> -   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 info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
-
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

Re: [PATCH] Prevent t6000 series from dropping useless sed.script in t/

[Jon Seymour]

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

Re: Where'd my GIT tree go?

[Jon Seymour]

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

Summary Of Jon's Recent Patches

[Jon Seymour]

Hi,

I've recently posted the following patches, in this order:

These ones are tidy ups:

[PATCH] Remove use of SHOWN flag
[PATCH] Move SEEN flag into epoch.h, replace use of VISITED flag with SEEN flag
[PATCH] Simplification - remove unnecessary list reversal from epoch.c

This series contains 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 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

Re: Summary Of Jon's Recent Patches

[Jon Seymour]

> 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

[PATCH 2/2] Fix --topo-order, --max-age interaction issue

[Jon Seymour]

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(-)

8238686fd422959dae50a908b3761aa545be1c4f
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -75,7 +75,7 @@ static int filter_commit(struct commit *
return CONTINUE;
if (max_age != -1 && (commit->date < max_age)) {
stop_traversal=1;
-   return merge_order?CONTINUE:STOP;
+   return (merge_order||topo_order)?CONTINUE:STOP;
}
if (max_count != -1 && !max_count--)
return STOP;

-
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

[PATCH 1/2] Add test case that shows --topo-order, --max-age break

[Jon Seymour]

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 deletions(-)

9b43fa5416abe653fd900abe491a38c5ec919758
diff --git a/t/t6003-rev-list-topo-order.sh b/t/t6003-rev-list-topo-order.sh
--- a/t/t6003-rev-list-topo-order.sh
+++ b/t/t6003-rev-list-topo-order.sh
@@ -289,16 +289,16 @@ EOF
 #
 # this test fails on --topo-order - a fix is required
 #
-#test_output_expect_success '--max-age=c3, --topo-order' "git-rev-list 
--topo-order --max-age=$(commit_date c3) l5" <http://vger.kernel.org/majordomo-info.html

[PATCH] Simplification - remove unnecessary list reversal from epoch.c

[Jon Seymour]

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, replace use of VISITED flag with SEEN flag
---

 epoch.c|   26 --
 rev-list.c |3 ++-
 2 files changed, 14 insertions(+), 15 deletions(-)

198b131890a2c6fc98ce4c151dc20bd4f548acf0
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -580,37 +580,35 @@ int sort_list_in_merge_order(struct comm
struct commit *base;
int ret = 0;
int action = CONTINUE;
-   struct commit_list *reversed = NULL;
+   struct commit_list *next = NULL;
 
-   for (; list; list = list->next) {
-   list->item->object.flags &= ~(SEEN|BOUNDARY|DISCONTINUITY);
-   commit_list_insert(list->item, &reversed);
-   }
+   for (next=list; next; next = next->next)
+   next->item->object.flags &= ~(SEEN|BOUNDARY|DISCONTINUITY);
 
-   if (!reversed)
+   if (!list)
return ret;
-   else if (!reversed->next) {
+   else if (!list->next) {
/*
 * If there is only one element in the list, we can sort it
 * using sort_in_merge_order.
 */
-   base = reversed->item;
+   base = list->item;
} else {
/*
 * Otherwise, we search for the base of the list.
 */
-   ret = find_base_for_list(reversed, &base);
+   ret = find_base_for_list(list, &base);
if (ret)
return ret;
if (base)
base->object.flags |= BOUNDARY;
 
-   while (reversed) {
-   struct commit * next = pop_commit(&reversed);
+   for (next=list; next; next=next->next) {
+   struct commit * next_item = next->item;
 
-   if (!(next->object.flags & SEEN) && next!=base) {
-   sort_first_epoch(next, &stack);
-   if (reversed) {
+   if (!(next_item->object.flags & SEEN) && 
next_item!=base) {
+   sort_first_epoch(next_item, &stack);
+   if (next) {
/*
 * If we have more commits 
 * to push, then the first
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -407,6 +407,7 @@ static struct commit *get_commit_referen
 int main(int argc, char **argv)
 {
struct commit_list *list = NULL;
+   struct commit_list **list_tail = &list;
int i, limited = 0;
 
for (i = 1 ; i < argc; i++) {
@@ -484,7 +485,7 @@ int main(int argc, char **argv)
if (commit->object.flags & SEEN)
continue;
commit->object.flags |= SEEN;
-   commit_list_insert(commit, &list);
+   list_tail = &commit_list_insert(commit, list_tail)->next;
}
 
if (!merge_order) { 

-
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

[PATCH] Move SEEN flag into epoch.h, replace use of VISITED flag with SEEN flag

[Jon Seymour]

SEEN and VISITED do the same thing.

This change moves the SEEN flag into epoch.h, then replaces
uses of VISITED with SEEN and removes the definition
of the VISITED flag.

The merge-order code needs to clear the SEEN flag
set by the argument parsing to ensure correct
operation. So it clears that 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 --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -387,7 +387,7 @@ static void push_onto_merge_order_stack(
 static void mark_ancestors_uninteresting(struct commit *commit)
 {
unsigned int flags = commit->object.flags;
-   int visited = flags & VISITED;
+   int visited = flags & SEEN;
int boundary = flags & BOUNDARY;
int uninteresting = flags & UNINTERESTING;
struct commit_list *next;
@@ -425,7 +425,7 @@ static void sort_first_epoch(struct comm
 {
struct commit_list *parents;
 
-   head->object.flags |= VISITED;
+   head->object.flags |= SEEN;
 
/*
 * TODO: By sorting the parents in a different order, we can alter the
@@ -450,14 +450,14 @@ static void sort_first_epoch(struct comm
mark_ancestors_uninteresting(parent);
}
 
-   if (!(parent->object.flags & VISITED)) {
+   if (!(parent->object.flags & SEEN)) {
if (parent->object.flags & BOUNDARY) {
if (*stack) {
die("something else is on the stack - 
%s",

sha1_to_hex((*stack)->item->object.sha1));
}
push_onto_merge_order_stack(stack, parent);
-   parent->object.flags |= VISITED;
+   parent->object.flags |= SEEN;
 
} else {
sort_first_epoch(parent, stack);
@@ -582,8 +582,10 @@ int sort_list_in_merge_order(struct comm
int action = CONTINUE;
struct commit_list *reversed = NULL;
 
-   for (; list; list = list->next)
+   for (; list; list = list->next) {
+   list->item->object.flags &= ~(SEEN|BOUNDARY|DISCONTINUITY);
commit_list_insert(list->item, &reversed);
+   }
 
if (!reversed)
return ret;
@@ -606,7 +608,7 @@ int sort_list_in_merge_order(struct comm
while (reversed) {
struct commit * next = pop_commit(&reversed);
 
-   if (!(next->object.flags & VISITED) && next!=base) {
+   if (!(next->object.flags & SEEN) && next!=base) {
sort_first_epoch(next, &stack);
if (reversed) {
/*
diff --git a/epoch.h b/epoch.h
--- a/epoch.h
+++ b/epoch.h
@@ -13,9 +13,7 @@ int sort_list_in_merge_order(struct comm
 /* Low bits are used by rev-list */
 #define UNINTERESTING   (1u<<10)
 #define BOUNDARY(1u<<11)
-#define VISITED (1u<<12)
+#define SEEN(1u<<12)
 #define DISCONTINUITY   (1u<<13)
-#define LAST_EPOCH_FLAG (1u<<14)
-
 
 #endif /* EPOCH_H */
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -5,9 +5,8 @@
 #include "blob.h"
 #include "epoch.h"
 
-#define SEEN   (1u << 0)
-#define INTERESTING(1u << 1)
-#define COUNTED(1u << 2)
+#define INTERESTING(1u << 0)
+#define COUNTED(1u << 1)
 
 static const char rev_list_usage[] =
"usage: git-rev-list [OPTION] commit-id \n"

-
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

[PATCH] Remove use of SHOWN flag

[Jon Seymour]

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 deletions(-)

28294b1e139ea3f7c08814e022246e42f9ab9fa3
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -8,7 +8,6 @@
 #define SEEN   (1u << 0)
 #define INTERESTING(1u << 1)
 #define COUNTED(1u << 2)
-#define SHOWN  (1u << 3)
 
 static const char rev_list_usage[] =
"usage: git-rev-list [OPTION] commit-id \n"
@@ -42,7 +41,6 @@ static int topo_order = 0;
 
 static void show_commit(struct commit *commit)
 {
-   commit->object.flags |= SHOWN;
if (show_breaks) {
prefix = "| ";
if (commit->object.flags & DISCONTINUITY) {
@@ -72,7 +70,7 @@ static int filter_commit(struct commit *
 {
if (stop_traversal && (commit->object.flags & BOUNDARY))
return STOP;
-   if (commit->object.flags & (UNINTERESTING|SHOWN))
+   if (commit->object.flags & UNINTERESTING)
return CONTINUE;
if (min_age != -1 && (commit->date > min_age))
return CONTINUE;

-
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

[PATCH] Ensure list insertion method does not depend on position of --merge-order argument

[Jon Seymour]

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 by me!
---

 rev-list.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

8723420366d839123ca4186c60469fd38fd4b798
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -411,10 +411,8 @@ static struct commit *get_commit_referen
 int main(int argc, char **argv)
 {
struct commit_list *list = NULL;
-   struct commit_list *(*insert)(struct commit *, struct commit_list **);
int i, limited = 0;
 
-   insert = insert_by_date;
for (i = 1 ; i < argc; i++) {
int flags;
char *arg = argv[i];
@@ -464,7 +462,6 @@ int main(int argc, char **argv)
}
if (!strcmp(arg, "--merge-order")) {
merge_order = 1;
-   insert = commit_list_insert;
continue;
}
if (!strcmp(arg, "--show-breaks")) {
@@ -491,10 +488,11 @@ int main(int argc, char **argv)
if (commit->object.flags & DUPCHECK)
continue;
commit->object.flags |= DUPCHECK;
-   insert(commit, &list);
+   commit_list_insert(commit, &list);
}
 
if (!merge_order) { 
+   sort_by_date(&list);
if (limited)
list = limit_list(list);
if (topo_order)

-
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

[PATCH 1/2] Add t/t6003 with some --topo-order tests

[Jon Seymour]

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-order.sh |  417 
 1 files changed, 417 insertions(+), 0 deletions(-)
 create mode 100755 t/t6003-rev-list-topo-order.sh

4adac54d3b1503168c54c8eb03e78ab09762c7f7
diff --git a/t/t6003-rev-list-topo-order.sh b/t/t6003-rev-list-topo-order.sh
new file mode 100755
--- /dev/null
+++ b/t/t6003-rev-list-topo-order.sh
@@ -0,0 +1,417 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Jon Seymour
+#
+
+test_description='Tests git-rev-list --topo-order functionality'
+
+. ./test-lib.sh
+. ../t6000-lib.sh # t6xxx specific functions
+
+list_duplicates()
+{
+"$@" | sort | uniq -d
+}
+
+date >path0
+git-update-cache --add path0
+save_tag tree git-write-tree
+on_committer_date "1971-08-16 00:00:00" hide_error save_tag root unique_commit 
root tree
+on_committer_date "1971-08-16 00:00:01" save_tag l0 unique_commit l0 tree -p 
root
+on_committer_date "1971-08-16 00:00:02" save_tag l1 unique_commit l1 tree -p l0
+on_committer_date "1971-08-16 00:00:03" save_tag l2 unique_commit l2 tree -p l1
+on_committer_date "1971-08-16 00:00:04" save_tag a0 unique_commit a0 tree -p l2
+on_committer_date "1971-08-16 00:00:05" save_tag a1 unique_commit a1 tree -p a0
+on_committer_date "1971-08-16 00:00:06" save_tag b1 unique_commit b1 tree -p a0
+on_committer_date "1971-08-16 00:00:07" save_tag c1 unique_commit c1 tree -p b1
+on_committer_date "1971-08-16 00:00:08" as_author [EMAIL PROTECTED] save_tag 
b2 unique_commit b2 tree -p b1
+on_committer_date "1971-08-16 00:00:09" save_tag b3 unique_commit b2 tree -p b2
+on_committer_date "1971-08-16 00:00:10" save_tag c2 unique_commit c2 tree -p 
c1 -p b2
+on_committer_date "1971-08-16 00:00:11" save_tag c3 unique_commit c3 tree -p c2
+on_committer_date "1971-08-16 00:00:12" save_tag a2 unique_commit a2 tree -p a1
+on_committer_date "1971-08-16 00:00:13" save_tag a3 unique_commit a3 tree -p a2
+on_committer_date "1971-08-16 00:00:14" save_tag b4 unique_commit b4 tree -p 
b3 -p a3
+on_committer_date "1971-08-16 00:00:15" save_tag a4 unique_commit a4 tree -p 
a3 -p b4 -p c3
+on_committer_date "1971-08-16 00:00:16" save_tag l3 unique_commit l3 tree -p a4
+on_committer_date "1971-08-16 00:00:17" save_tag l4 unique_commit l4 tree -p l3
+on_committer_date "1971-08-16 00:00:18" save_tag l5 unique_commit l5 tree -p l4
+on_committer_date "1971-08-16 00:00:19" save_tag m1 unique_commit m1 tree -p 
a4 -p c3
+on_committer_date "1971-08-16 00:00:20" save_tag m2 unique_commit m2 tree -p 
c3 -p a4
+on_committer_date "1971-08-16 00:00:21" hide_error save_tag alt_root 
unique_commit alt_root tree
+on_committer_date "1971-08-16 00:00:22" save_tag r0 unique_commit r0 tree -p 
alt_root
+on_committer_date "1971-08-16 00:00:23" save_tag r1 unique_commit r1 tree -p r0
+on_committer_date "1971-08-16 00:00:24" save_tag l5r1 unique_commit l5r1 tree 
-p l5 -p r1
+on_committer_date "1971-08-16 00:00:25" save_tag r1l5 unique_commit r1l5 tree 
-p r1 -p l5
+
+
+#
+# note: as of 20/6, it isn't possible to create duplicate parents, so this
+# can't be tested.
+#
+#on_committer_date "1971-08-16 00:00:20" save_tag m3 unique_commit m3 tree -p 
c3 -p a4 -p c3
+hide_error save_tag e1 as_author [EMAIL PROTECTED] unique_commit e1 tree
+save_tag e2 as_author [EMAIL PROTECTED] unique_commit e2 tree -p e1
+save_tag f1 as_author [EMAIL PROTECTED] unique_commit f1 tree -p e1
+save_tag e3 as_author [EMAIL PROTECTED] unique_commit e3 tree -p e2
+save_tag f2 as_author [EMAIL PROTECTED] unique_commit f2 tree -p f1
+save_tag e4 as_author [EMAIL PROTECTED] unique_commit e4 tree -p e3 -p f2
+save_tag e5 as_author [EMAIL PROTECTED] unique_commit e5 tree -p e4
+save_tag f3 as_author [EMAIL PROTECTED] unique_commit f3 tree -p f2
+save_tag f4 as_author [EMAIL PROTECTED] unique_commit f4 tree -p f3
+save_tag e6 as_author [EMAIL PROTECTED] unique_commit e6 tree -p e5 -p f4
+save_tag f5 as_author [EMAIL PROTECTED] unique_commit f5 tree -p f4
+save_tag f6 as_author [EMAIL PROTECTED] unique_commit f6 tree -p f5 -p e6
+save_tag e7 as_author [EMAIL PROTECTED] unique_commit e7 tree -p e6
+save_tag e8 as_author [EMAIL PROTECTED] unique_commit e8 tree -p e7
+save_tag e9 as_author [EMAIL PROTECTED] unique_commit e9 tree -p e8
+save_tag f7 as_author [EMAIL PROTECTED] unique_commit f7 tree -p f6
+save_tag f8 as_author [EMAIL PROTECTED] unique_commit f8 tree -p f7
+save_tag f9 as_author [EMAIL PROTECTED] unique_commit f9 tree -p f8
+save_tag e10 as_author [EMA

[PATCH 2/2] Write sed script directly into temp file, rather than a variable

[Jon Seymour]

When sed uses \n rather than ; as a separator (for BSD sed(1) compat),
it is cleaner to use a file directly, rather than an environment
variable containing \n characters.

This change changes t/t6000 write to sed.script directly and changes
the other tests to remove knowledge of sed.script.

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 deletions(-)

8e14d7142551c4eca6718894943e33a2a0a2a14f
diff --git a/t/t6000-lib.sh b/t/t6000-lib.sh
--- a/t/t6000-lib.sh
+++ b/t/t6000-lib.sh
@@ -1,6 +1,6 @@
 [ -d .git/refs/tags ] || mkdir -p .git/refs/tags
 
-sed_script="";
+:> sed.script
 
 # Answer the sha1 has associated with the tag. The tag must exist in .git or 
.git/refs/tags
 tag()
@@ -21,7 +21,7 @@ unique_commit()
 }
 
 # Save the output of a command into the tag specified. Prepend
-# a substitution script for the tag onto the front of $sed_script
+# a substitution script for the tag onto the front of sed.script
 save_tag()
 {
_tag=$1 
@@ -29,14 +29,16 @@ save_tag()
shift 1
"$@" >.git/refs/tags/$_tag
 
-   sed_script="s/$(tag $_tag)/$_tag/g
-$sed_script"
+echo "s/$(tag $_tag)/$_tag/g" > sed.script.tmp
+   cat sed.script >> sed.script.tmp
+   rm sed.script
+   mv sed.script.tmp sed.script
 }
 
 # Replace unhelpful sha1 hashses with their symbolic equivalents 
 entag()
 {
-   sed "$sed_script"
+   sed -f sed.script
 }
 
 # Execute a command after first saving, then setting the GIT_AUTHOR_EMAIL
diff --git a/t/t6001-rev-list-merge-order.sh b/t/t6001-rev-list-merge-order.sh
--- a/t/t6001-rev-list-merge-order.sh
+++ b/t/t6001-rev-list-merge-order.sh
@@ -103,15 +103,6 @@ save_tag g4 unique_commit g6 tree -p g3 
 
 tag l5 > .git/HEAD
 
-#
-# cd to t/trash and use 
-#
-#git-rev-list ... 2>&1 | sed "$(cat sed.script)" 
-#
-# if you ever want to manually debug the operation of git-rev-list
-#
-echo $sed_script > sed.script
-
 test_expect_success 'rev-list has correct number of entries' 'git-rev-list 
HEAD | wc -l | tr -s " "' <&1 | sed "$(cat sed.script)" 
-#
-# if you ever want to manually debug the operation of git-rev-list
-#
-echo $sed_script > sed.script
-
 test_sequence()
 {
_bisect_option=$1   
diff --git a/t/t6003-rev-list-topo-order.sh b/t/t6003-rev-list-topo-order.sh
--- a/t/t6003-rev-list-topo-order.sh
+++ b/t/t6003-rev-list-topo-order.sh
@@ -79,15 +79,6 @@ save_tag g4 unique_commit g6 tree -p g3 
 
 tag l5 > .git/HEAD
 
-#
-# cd to t/trash and use 
-#
-#git-rev-list ... 2>&1 | sed "$(cat sed.script)" 
-#
-# if you ever want to manually debug the operation of git-rev-list
-#
-echo "$sed_script" | tr ' ' \\012 > sed.script
-
 test_expect_success 'rev-list has correct number of entries' 'git-rev-list 
HEAD | wc -l | tr -s " "' <http://vger.kernel.org/majordomo-info.html

[PATCH 4/13] Add a topological sort procedure to commit.c [rev 4]

[Jon Seymour]

This patch introduces an in-place topological sort procedure to commit.c.

Given a list of commits, sort_in_topological_order() will perform an in-place
topological sort of that list.

The invariant that applies to the resulting list is:

   a reachable from b => ord(b) < ord(a)

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 no observable consequences since nothing
in this patch calls it. A future patch will use this algorithm to provide
support for a --topo-order flag.

This patch is a complete replacement for earlier revisions of this patch.

[rev 2]
  * incorporates Junio's questions/comments as commentary,
  * adds object.util save/restore functionality so that no
assumption is made about the pre-existing state of object.util
upon entry to the procedure.
[rev 3]
  * removed object.util save/restore
  * added more documentation to header about pre-conditions
[rev 4]
  * re-applied rev 3 to new patch series - no other change
---

 commit.c |  107 ++
 commit.h |   13 
 2 files changed, 120 insertions(+), 0 deletions(-)

155c21a7e0295deab710345d22f0551706a7f84a
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -3,6 +3,22 @@
 #include "commit.h"
 #include "cache.h"
 
+struct sort_node
+{
+   /*
+ * the number of children of the associated commit
+ * that also occur in the list being sorted.
+ */
+   unsigned int indegree;
+
+   /*
+ * reference to original list item that we will re-use
+ * on output.
+ */
+   struct commit_list * list_item;
+
+};
+
 const char *commit_type = "commit";
 
 enum cmit_fmt get_commit_format(const char *arg)
@@ -346,3 +362,94 @@ int count_parents(struct commit * commit
 return count;
 }
 
+/*
+ * Performs an in-place topological sort on the list supplied.
+ */
+void sort_in_topological_order(struct commit_list ** list)
+{
+   struct commit_list * next = *list;
+   struct commit_list * work = NULL;
+   struct commit_list ** pptr = list;
+   struct sort_node * nodes;
+   struct sort_node * next_nodes;
+   int count = 0;
+
+   /* determine the size of the list */
+   while (next) {
+   next = next->next;
+   count++;
+   }
+   /* allocate an array to help sort the list */
+   nodes = xcalloc(count, sizeof(*nodes));
+   /* link the list to the array */
+   next_nodes = nodes;
+   next=*list;
+   while (next) {
+   next_nodes->list_item = next;
+   next->item->object.util = next_nodes;
+   next_nodes++;
+   next = next->next;
+   }
+   /* update the indegree */
+   next=*list;
+   while (next) {
+   struct commit_list * parents = next->item->parents;
+   while (parents) {
+   struct commit * parent=parents->item;
+   struct sort_node * pn = (struct sort_node 
*)parent->object.util;
+   
+   if (pn)
+   pn->indegree++;
+   parents=parents->next;
+   }
+   next=next->next;
+   }
+   /* 
+ * find the tips
+ *
+ * tips are nodes not reachable from any other node in the list 
+ * 
+ * the tips serve as a starting set for the work queue.
+ */
+   next=*list;
+   while (next) {
+   struct sort_node * node = (struct sort_node 
*)next->item->object.util;
+
+   if (node->indegree == 0) {
+   commit_list_insert(next->item, &work);
+   }
+   next=next->next;
+   }
+   /* process the list in topological order */
+   while (work) {
+   struct commit * work_item = pop_commit(&work);
+   struct sort_node * work_node = (struct sort_node 
*)work_item->object.util;
+   struct commit_list * parents = work_item->parents;
+
+   while (parents) {
+   struct commit * parent=parents->item;
+   struct sort_node * pn = (struct sort_node 
*)parent->object.util;
+   
+   if (pn) {
+   /* 
+* parents are only enqueued for emission 
+ * when all their children have been emitted 
thereby
+ * guaranteeing topological order.
+   

[PATCH 2/13] Swap order of insert_by_date arguments

[Jon Seymour]

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 +-
 epoch.c|4 ++--
 rev-list.c |2 +-
 4 files changed, 12 insertions(+), 8 deletions(-)

486d4dee9772a59b955574951e8d4946b75cf9fa
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -147,7 +147,7 @@ void free_commit_list(struct commit_list
}
 }
 
-void insert_by_date(struct commit_list **list, struct commit *item)
+struct commit_list * insert_by_date(struct commit *item, struct commit_list 
**list)
 {
struct commit_list **pp = list;
struct commit_list *p;
@@ -157,7 +157,7 @@ void insert_by_date(struct commit_list *
}
pp = &p->next;
}
-   commit_list_insert(item, pp);
+   return commit_list_insert(item, pp);
 }
 

@@ -165,7 +165,7 @@ void sort_by_date(struct commit_list **l
 {
struct commit_list *ret = NULL;
while (*list) {
-   insert_by_date(&ret, (*list)->item);
+   insert_by_date((*list)->item, &ret);
*list = (*list)->next;
}
*list = ret;
@@ -186,7 +186,7 @@ struct commit *pop_most_recent_commit(st
parse_commit(commit);
if (!(commit->object.flags & mark)) {
commit->object.flags |= mark;
-   insert_by_date(list, commit);
+   insert_by_date(commit, list);
}
parents = parents->next;
}
diff --git a/commit.h b/commit.h
--- a/commit.h
+++ b/commit.h
@@ -44,7 +44,11 @@ enum cmit_fmt {
 extern enum cmit_fmt get_commit_format(const char *arg);
 extern unsigned long pretty_print_commit(enum cmit_fmt fmt, const char *msg, 
unsigned long len, char *buf, unsigned long space);
 
-void insert_by_date(struct commit_list **list, struct commit *item);
+/*
+ * Inserts item into the list specified in most recent commit date first order.
+ * A pointer to the most recently inserted item is returned.
+ */
+struct commit_list * insert_by_date(struct commit *item, struct commit_list 
**list);
 
 /** Removes the first commit from a list sorted by date, and adds all
  * of its parents.
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -255,11 +255,11 @@ static int find_base_for_list(struct com
 
if (!parent_node) {
parent_node = new_mass_counter(parent, 
&distribution);
-   insert_by_date(&pending, parent);
+   insert_by_date(parent, &pending);
commit_list_insert(parent, &cleaner);
} else {
if (!compare(&parent_node->pending, 
get_zero()))
-   insert_by_date(&pending, 
parent);
+   insert_by_date(parent, 
&pending);
add(&parent_node->pending, 
&parent_node->pending, &distribution);
}
}
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -483,7 +483,7 @@ int main(int argc, char **argv)
if (!commit)
continue;
if (!merge_order) 
-   insert_by_date(&list, commit);
+   insert_by_date(commit, &list);
else 
commit_list_insert(commit, &list);
}

-
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

[PATCH 1/13] Temporary fixup to rev-list.c to restore expected order of arguments presented to --merge-order sort.

[Jon Seymour]

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 changed, 4 insertions(+), 1 deletions(-)

c63fe4678d33db15db076606f7a133868e91f1bc
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -482,7 +482,10 @@ int main(int argc, char **argv)
commit = get_commit_reference(arg, flags);
if (!commit)
continue;
-   insert_by_date(&list, commit);
+   if (!merge_order) 
+   insert_by_date(&list, commit);
+   else 
+   commit_list_insert(commit, &list);
}
 
if (!merge_order) { 

-
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

[PATCH 3/13] Introduce struct rev_list_fns to rev-list.c to reduce amount of conditional processing.

[Jon Seymour]

Per a suggestion from Linus, I have introduced the rev_list_fns structure into
rev-list.c

The intent of this change is to make use of a strategy pattern to configure 
the behaviour of git-rev-list and so help limit the ever-increasing 
proliferation of boolean switches throughout the body of the 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 <[EMAIL PROTECTED]>
---

 Documentation/git-rev-list.txt |2 +
 rev-list.c |   54 +++-
 2 files changed, 38 insertions(+), 18 deletions(-)

77418fc85cc40e56ef66c5031025399c5e6ed787
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -57,7 +57,7 @@ Commits marked with (^) are not parents 
 These "breaks" represent necessary discontinuities implied by trying to
 represent an arbtirary DAG in a linear form.
 
-*--show-breaks* is only valid if *--merge-order* is also specified.
+*--show-breaks* implies **-merge-order*.
 
 Author
 --
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -39,6 +39,12 @@ static int merge_order = 0;
 static int show_breaks = 0;
 static int stop_traversal = 0;
 
+struct rev_list_fns {
+   struct commit_list * (*insert)(struct commit *, struct commit_list **);
+   struct commit_list * (*limit)(struct commit_list *);
+   void (*process)(struct commit_list *);
+};
+
 static void show_commit(struct commit *commit)
 {
commit->object.flags |= SHOWN;
@@ -410,9 +416,30 @@ static struct commit *get_commit_referen
die("%s is unknown object", name);
 }
 
+static void merge_order_sort(struct commit_list * list)
+{
+   if (sort_list_in_merge_order(list, &process_commit))
+   die("commit graph traversal failed");
+}
+
+struct rev_list_fns default_fns = {
+   &insert_by_date,
+   &limit_list,
+&show_commit_list
+};
+
+struct rev_list_fns merge_order_fns = {
+   &commit_list_insert,
+   NULL,
+   &merge_order_sort
+};
+
 int main(int argc, char **argv)
 {
struct commit_list *list = NULL;
+   struct commit_list *sorted = NULL;
+   struct commit_list **list_tail = &list;
+   struct rev_list_fns * fns = &default_fns;
int i, limited = 0;
 
for (i = 1 ; i < argc; i++) {
@@ -468,6 +495,7 @@ int main(int argc, char **argv)
}
if (!strcmp(arg, "--show-breaks")) {
show_breaks = 1;
+   merge_order = 1;
continue;
}
 
@@ -477,26 +505,18 @@ int main(int argc, char **argv)
arg++;
limited = 1;
}
-   if (show_breaks && !merge_order)
-   usage(rev_list_usage);
commit = get_commit_reference(arg, flags);
if (!commit)
continue;
-   if (!merge_order) 
-   insert_by_date(commit, &list);
-   else 
-   commit_list_insert(commit, &list);
+   list_tail = &commit_list_insert(commit, list_tail)->next;
}
-
-   if (!merge_order) { 
-   if (limited)
-   list = limit_list(list);
-   show_commit_list(list);
-   } else {
-   if (sort_list_in_merge_order(list, &process_commit)) {
- die("merge order sort failed\n");
-   }
-   }
-
+   if (merge_order)
+   fns=&merge_order_fns;
+   while (list)
+   fns->insert(pop_commit(&list), &sorted);
+   list=sorted;
+   if (limited && fns->limit)
+   list = fns->limit(list);
+   fns->process(list);
return 0;
 }

-
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

[PATCH 0/13] Patch Series

[Jon Seymour]

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 to restore expected order of 
arguments presented to --merge-order sort.
[PATCH 2/13] Swap order of insert_by_date arguments
[PATCH 3/13] Introduce struct rev_list_fns to rev-list.c to reduce amount of 
conditional processing.
[PATCH 4/13] Add a topological sort procedure to commit.c [rev 4]
[PATCH 5/13] Introduce --topo-order switch to git-rev-list
[PATCH 6/13] Change gitk so that it uses --topo-order rather than --merge-order
[PATCH 7/13] Tidy up - slight simplification of rev-list.c
[PATCH 8/13] Fix handling of duplicates by topological order.

Tidy up and extension of t6xxx test cases

[PATCH 9/13] Factor out useful test case infrastructure from t/t6001... into 
t/t6000-lib.sh
[PATCH 10/13] Introduce unit tests for git-rev-list --bisect
[PATCH 11/13] Change the sed seperator in t/t6000-lib.sh.

Test for and fix of recently discovered --merge-order bug

[PATCH 12/13] Add a t/t6001 test case for a --merge-order bug
[PATCH 13/13] Fixes a problem with --merge-order A B (A is linear descendent of 
a merge B)
-
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

[PATCH 6/13] Change gitk so that it uses --topo-order rather than --merge-order

[Jon Seymour]

This change is made so that gitk --all produces the same result for
every user irrespective of whether git-rev-parse --all produces
the same result for every user. By using --topo-order rather than
--merge-order this can be guaranteed and the existing (non-timestamp dependent)
behaviour of --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
start list, whereas git-rev-list --merge-order produces an order that is 
deliberately
sensitive to the order of the start list.

Linus wants gitk --all to behave the same way, irrespective of what order
git-rev-parse --all produces its output. I want --merge-order to keep its
existing behaviour, so we agreed on this compromise whereby gitk uses
--topo-order rather than --merge-order by default.

My understanding of your code is that you only expect a minimal topological 
ordering
guarantee and the ordering produced by --topo-order should be sufficient
for your needs - that is, you don't rely on the other aspect of the
--merge-order invariant.

I'll leave it to you and Linus to decide how you want to manage the merge 
between
your HEAD and Linus'.
---

 gitk |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

19c9032b06b370511ef1091434df0d1d644fee06
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -37,7 +37,7 @@ proc getcommits {rargs} {
set parsed_args $rargs
 }
 if [catch {
-   set commfd [open "|git-rev-list --header --merge-order $parsed_args" r]
+   set commfd [open "|git-rev-list --header --topo-order $parsed_args" r]
 } err] {
puts stderr "Error executing git-rev-list: $err"
exit 1

-
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

[PATCH 5/13] Introduce --topo-order switch to git-rev-list

[Jon Seymour]

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-by: Jon Seymour <[EMAIL PROTECTED]>
---

 Documentation/git-rev-list.txt |9 +++--
 rev-list.c |   27 +--
 2 files changed, 32 insertions(+), 4 deletions(-)

99d3a2318171f611f1c186a7ed4881b2f34b6b49
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -9,13 +9,15 @@ git-rev-list - Lists commit objects in r
 
 SYNOPSIS
 
-'git-rev-list' [ *--max-count*=number ] [ *--max-age*=timestamp ] [ 
*--min-age*=timestamp ] [ *--merge-order* [ *--show-breaks* ] ] 
+'git-rev-list' [ *--max-count*=number ] [ *--max-age*=timestamp ] [ 
*--min-age*=timestamp ] [ *--merge-order* ] [ *--show-breaks* ] [ 
*--topo-order* ] ... ^...
 
 DESCRIPTION
 ---
 Lists commit objects in reverse chronological order starting at the
 given commit, taking ancestry relationship into account.  This is
-useful to produce human-readable log output.
+useful to produce human-readable log output. If prune points are specified
+with ^... arguments, the output will not include any commits reachable
+from (and including) the prune points.
 
 If *--merge-order* is specified, the commit history is decomposed into a
 unique sequence of minimal, non-linear epochs and maximal, linear epochs.
@@ -59,6 +61,9 @@ represent an arbtirary DAG in a linear f
 
 *--show-breaks* implies **-merge-order*.
 
+If *--topo-order* is specified, the commit history is sorted in a topological
+order that is weaker than the topological order generated by *--merge-order*.
+
 Author
 --
 Written by Linus Torvalds <[EMAIL PROTECTED]>
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -20,6 +20,7 @@ static const char rev_list_usage[] =
  "  --unpacked\n"
  "  --header\n"
  "  --pretty\n"
+ "  --topo-order\n"
  "  --merge-order [ --show-breaks ]";
 
 static int unpacked = 0;
@@ -38,10 +39,12 @@ static enum cmit_fmt commit_format = CMI
 static int merge_order = 0;
 static int show_breaks = 0;
 static int stop_traversal = 0;
+static int topo_order = 0;
 
 struct rev_list_fns {
struct commit_list * (*insert)(struct commit *, struct commit_list **);
struct commit_list * (*limit)(struct commit_list *);
+   void (*sort)(struct commit_list **);
void (*process)(struct commit_list *);
 };
 
@@ -425,12 +428,21 @@ static void merge_order_sort(struct comm
 struct rev_list_fns default_fns = {
&insert_by_date,
&limit_list,
-&show_commit_list
+   NULL,
+   &show_commit_list
+};
+
+struct rev_list_fns topo_order_fns = {
+   &insert_by_date,
+   &limit_list,
+   &sort_in_topological_order,
+   &show_commit_list
 };
 
 struct rev_list_fns merge_order_fns = {
&commit_list_insert,
NULL,
+   NULL,
&merge_order_sort
 };
 
@@ -439,7 +451,7 @@ int main(int argc, char **argv)
struct commit_list *list = NULL;
struct commit_list *sorted = NULL;
struct commit_list **list_tail = &list;
-   struct rev_list_fns * fns = &default_fns;
+   struct rev_list_fns * fns = NULL;
int i, limited = 0;
 
for (i = 1 ; i < argc; i++) {
@@ -498,6 +510,11 @@ int main(int argc, char **argv)
merge_order = 1;
continue;
}
+   if (!strcmp(arg, "--topo-order")) {
+   topo_order = 1;
+   limited=1;
+   continue;
+   }
 
flags = 0;
if (*arg == '^') {
@@ -512,11 +529,17 @@ int main(int argc, char **argv)
}
if (merge_order)
fns=&merge_order_fns;
+   else if (topo_order)
+   fns=&topo_order_fns;
+   else
+   fns=&default_fns;
while (list)
fns->insert(pop_commit(&list), &sorted);
list=sorted;
if (limited && fns->limit)
list = fns->limit(list);
+   if (fns->sort)
+   fns->sort(&list);
fns->process(list);
return 0;
 }

-
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

[PATCH 10/13] Introduce unit tests for git-rev-list --bisect

[Jon Seymour]

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/t6002-rev-list-bisect.sh

5c47ce16a5b71238bddd7ae75cc694b9479fd0d9
diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh
new file mode 100755
--- /dev/null
+++ b/t/t6002-rev-list-bisect.sh
@@ -0,0 +1,247 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Jon Seymour
+#
+test_description='Tests git-rev-list --bisect functionality'
+
+. ./test-lib.sh
+. ../t6000-lib.sh
+
+bc_expr()
+{
+bc <=0) { return x; } else { return -x; } }
+define floor(x) { save=scale; scale=0; result=x/1; scale=save; return result; }
+$*
+EOF
+}
+
+# usage: test_bisection max-diff bisect-option head ^prune...
+#
+# e.g. test_bisection 1 --bisect l1 ^l0
+#
+test_bisection_diff()
+{
+   _max_diff=$1
+   _bisect_option=$2
+   shift 2
+   _bisection=$(git-rev-list $_bisect_option "$@")
+   _list_size=$(git-rev-list "$@" | wc -l)
+_head=$1
+   shift 1
+   _bisection_size=$(git-rev-list $_bisection "$@" | wc -l)
+   [ -n "$_list_size" -a -n "$_bisection_size" ] || error 
"test_bisection_diff failed"
+   test_expect_success "bisection diff $_bisect_option $_head $* <= 
$_max_diff" "[ $(bc_expr "floor(abs($_list_size/2)-$_bisection_size)") -le 
$_max_diff ]"
+}
+
+date >path0
+git-update-cache --add path0
+save_tag tree git-write-tree
+on_committer_date "1971-08-16 00:00:00" hide_error save_tag root unique_commit 
root tree
+on_committer_date "1971-08-16 00:00:01" save_tag l0 unique_commit l0 tree -p 
root
+on_committer_date "1971-08-16 00:00:02" save_tag l1 unique_commit l1 tree -p l0
+on_committer_date "1971-08-16 00:00:03" save_tag l2 unique_commit l2 tree -p l1
+on_committer_date "1971-08-16 00:00:04" save_tag a0 unique_commit a0 tree -p l2
+on_committer_date "1971-08-16 00:00:05" save_tag a1 unique_commit a1 tree -p a0
+on_committer_date "1971-08-16 00:00:06" save_tag b1 unique_commit b1 tree -p a0
+on_committer_date "1971-08-16 00:00:07" save_tag c1 unique_commit c1 tree -p b1
+on_committer_date "1971-08-16 00:00:08" save_tag b2 unique_commit b2 tree -p b1
+on_committer_date "1971-08-16 00:00:09" save_tag b3 unique_commit b2 tree -p b2
+on_committer_date "1971-08-16 00:00:10" save_tag c2 unique_commit c2 tree -p 
c1 -p b2
+on_committer_date "1971-08-16 00:00:11" save_tag c3 unique_commit c3 tree -p c2
+on_committer_date "1971-08-16 00:00:12" save_tag a2 unique_commit a2 tree -p a1
+on_committer_date "1971-08-16 00:00:13" save_tag a3 unique_commit a3 tree -p a2
+on_committer_date "1971-08-16 00:00:14" save_tag b4 unique_commit b4 tree -p 
b3 -p a3
+on_committer_date "1971-08-16 00:00:15" save_tag a4 unique_commit a4 tree -p 
a3 -p b4 -p c3
+on_committer_date "1971-08-16 00:00:16" save_tag l3 unique_commit l3 tree -p a4
+on_committer_date "1971-08-16 00:00:17" save_tag l4 unique_commit l4 tree -p l3
+on_committer_date "1971-08-16 00:00:18" save_tag l5 unique_commit l5 tree -p l4
+tag l5 > .git/HEAD
+
+
+# E
+#/ \
+#   e1  |
+#   |   |
+#   e2  |
+#   |   |
+#   e3  |
+#   |   |
+#   e4  |
+#   |   |
+#   |   f1
+#   |   |
+#   |   f2
+#   |   |
+#   |   f3
+#   |   |
+#   |   f4
+#   |   |
+#   e5  |
+#   |   |
+#   e6  |
+#   |   |
+#   e7  |
+#   |   |
+#   e8  |
+#\ /
+# F
+
+
+on_committer_date "1971-08-16 00:00:00" hide_error save_tag F unique_commit F 
tree
+on_committer_date "1971-08-16 00:00:01" save_tag e8 unique_commit e8 tree -p F
+on_committer_date "1971-08-16 00:00:02" save_tag e7 unique_commit e7 tree -p e8
+on_committer_date "1971-08-16 00:00:03" save_tag e6 unique_commit e6 tree -p e7
+on_committer_date "1971-08-16 00:00:04" save_tag e5 unique_commit e5 tree -p e6
+on_committer_date "1971-08-16 00:00:05" save_tag f4 unique_commit f4 tree -p F
+on_committer_date "1971-08-16 00:00:06" save_tag f3 unique_commit f3 tree -p f4
+on_committer_date "1971-08-16 00:00:07" save_tag f2 unique_commit f2 tree -p f3
+on_committer_date "1971-08-16 00:00:08" save_tag f1 unique_commit f1 tree -p f2
+on_committer_date "1971-08-16 00:00:09" save_tag e4 unique_commit e4 tree -p e5
+on_committer_date "1971-08-16 00:00:10" save_tag e3 unique_commit e3 tree -p e4
+on_committer_date "1971-08-16 00:00:11" save_tag e2 unique_commit e2 tree -p e3
+on_committer_date "1971-08-16 00:00:12" save_tag e1 unique_commit e1 tree -p e2
+on_committer_date "1971-08-16 00:00:1

[PATCH 8/13] Fix handling of duplicates by topological order.

[Jon Seymour]

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 changed, 24 insertions(+), 15 deletions(-)

60a355172fdf6583465e1c237a3e82af64065332
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -374,11 +374,17 @@ void sort_in_topological_order(struct co
struct sort_node * next_nodes;
int count = 0;
 
-   /* determine the size of the list */
-   while (next) {
-   next = next->next;
-   count++;
+   /* determine the size of the list and elide duplicates */
+   while (*pptr) {
+   next=*pptr;
+   if (!(next->item->object.flags & DUPCHECK)) {
+   count++;
+   next->item->object.flags |= DUPCHECK;
+   pptr=&next->next;
+   } else
+   *pptr=next->next;
}
+   pptr=list;
/* allocate an array to help sort the list */
nodes = xcalloc(count, sizeof(*nodes));
/* link the list to the array */
@@ -387,6 +393,7 @@ void sort_in_topological_order(struct co
while (next) {
next_nodes->list_item = next;
next->item->object.util = next_nodes;
+   next->item->object.flags &= ~DUPCHECK;
next_nodes++;
next = next->next;
}
diff --git a/commit.h b/commit.h
--- a/commit.h
+++ b/commit.h
@@ -4,6 +4,9 @@
 #include "object.h"
 #include "tree.h"
 
+#define DUPCHECK (1u<<0)
+#define LAST_COMMIT_FLAG (DUPCHECK)
+
 struct commit_list {
struct commit *item;
struct commit_list *next;
diff --git a/epoch.h b/epoch.h
--- a/epoch.h
+++ b/epoch.h
@@ -1,6 +1,6 @@
 #ifndef EPOCH_H
 #define EPOCH_H
-
+#include "commit.h"
 
 // return codes for emitter_func
 #define STOP 0
@@ -10,12 +10,11 @@ typedef int (*emitter_func) (struct comm
 
 int sort_list_in_merge_order(struct commit_list *list, emitter_func emitter);
 
-#define UNINTERESTING   (1u<<2)
-#define BOUNDARY(1u<<3)
-#define VISITED (1u<<4)
-#define DISCONTINUITY   (1u<<5)
-#define DUPCHECK(1u<<6)
-#define LAST_EPOCH_FLAG (1u<<6)
+#define UNINTERESTING   (LAST_COMMIT_FLAG<<1)
+#define BOUNDARY(LAST_COMMIT_FLAG<<2)
+#define VISITED (LAST_COMMIT_FLAG<<3)
+#define DISCONTINUITY   (LAST_COMMIT_FLAG<<4)
+#define LAST_EPOCH_FLAG (LAST_COMMIT_FLAG<<4)
 
 
 #endif /* EPOCH_H */
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -5,10 +5,10 @@
 #include "blob.h"
 #include "epoch.h"
 
-#define SEEN   (1u << 0)
-#define INTERESTING(1u << 1)
-#define COUNTED(1u << 2)
-#define SHOWN  (LAST_EPOCH_FLAG << 2)
+#define SEEN(LAST_EPOCH_FLAG << 1)
+#define INTERESTING (LAST_EPOCH_FLAG << 2)
+#define COUNTED (LAST_EPOCH_FLAG << 3)
+#define SHOWN   (LAST_EPOCH_FLAG << 4)
 
 static const char rev_list_usage[] =
"usage: git-rev-list [OPTION] commit-id \n"

-
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

[PATCH 7/13] Tidy up - slight simplification of rev-list.c

[Jon Seymour]

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 thing from a
readability point of view. Let me know if you disagree.
---

 rev-list.c |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)

f5d3f5e7540acdd319da2697a9ad39d1cfe09796
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -78,19 +78,15 @@ static void show_commit(struct commit *c
 
 static int filter_commit(struct commit * commit)
 {
-   if (merge_order && stop_traversal && commit->object.flags & BOUNDARY)
+   if (stop_traversal && (commit->object.flags & BOUNDARY))
return STOP;
if (commit->object.flags & (UNINTERESTING|SHOWN))
return CONTINUE;
if (min_age != -1 && (commit->date > min_age))
return CONTINUE;
if (max_age != -1 && (commit->date < max_age)) {
-   if (!merge_order)
-   return STOP;
-   else {
-   stop_traversal = 1;
-   return CONTINUE;
-   }
+   stop_traversal=1;
+   return merge_order?CONTINUE:STOP;
}
if (max_count != -1 && !max_count--)
return STOP;

-
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

[PATCH 11/13] Change the sed seperator in t/t6000-lib.sh.

[Jon Seymour]

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 to the code that was moved from t/t6001... into t/t6000-lib.sh
---

 t/t6000-lib.sh |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

b49ca001a8b60bdcdce989a65b120a7183486cf8
diff --git a/t/t6000-lib.sh b/t/t6000-lib.sh
--- a/t/t6000-lib.sh
+++ b/t/t6000-lib.sh
@@ -28,7 +28,9 @@ save_tag()
[ -n "$_tag" ] || error "usage: save_tag tag commit-args ..."
shift 1
"$@" >.git/refs/tags/$_tag
-   sed_script="s/$(tag $_tag)/$_tag/g${sed_script+;}$sed_script"
+
+   sed_script="s/$(tag $_tag)/$_tag/g
+$sed_script"
 }
 
 # Replace unhelpful sha1 hashses with their symbolic equivalents 

-
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

[PATCH 13/13] Fixes a problem with --merge-order A B (A is linear descendent of a merge B)

[Jon Seymour]

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/epoch.c
@@ -612,7 +612,7 @@ int sort_list_in_merge_order(struct comm
while (reversed) {
struct commit * next = pop_commit(&reversed);
 
-   if (!(next->object.flags & VISITED)) {
+   if (!(next->object.flags & VISITED) && next!=base) {
sort_first_epoch(next, &stack);
if (reversed) {
/*

-
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

[PATCH 12/13] Add a t/t6001 test case for a --merge-order bug

[Jon Seymour]

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-merge-order.sh |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

eb702818ec4e0db40da78dd27623d33fdbaabe8b
diff --git a/t/t6001-rev-list-merge-order.sh b/t/t6001-rev-list-merge-order.sh
--- a/t/t6001-rev-list-merge-order.sh
+++ b/t/t6001-rev-list-merge-order.sh
@@ -438,6 +438,26 @@ a2
 a1
 EOF
 
+test_output_expect_success "--merge-order a4 l3" "git-rev-list --merge-order 
a4 l3" <http://vger.kernel.org/majordomo-info.html

[PATCH 9/13] Factor out useful test case infrastructure from t/t6001... into t/t6000-lib.sh

[Jon Seymour]

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-lib.sh  |  105 +
 t/t6001-rev-list-merge-order.sh |  112 ---
 2 files changed, 106 insertions(+), 111 deletions(-)
 create mode 100644 t/t6000-lib.sh

98aea4ed9ea8b2c17b65502cab27b77beb6fdaab
diff --git a/t/t6000-lib.sh b/t/t6000-lib.sh
new file mode 100644
--- /dev/null
+++ b/t/t6000-lib.sh
@@ -0,0 +1,105 @@
+[ -d .git/refs/tags ] || mkdir -p .git/refs/tags
+
+sed_script="";
+
+# Answer the sha1 has associated with the tag. The tag must exist in .git or 
.git/refs/tags
+tag()
+{
+   _tag=$1
+   [ -f .git/refs/tags/$_tag ] || error "tag: \"$_tag\" does not exist"
+   cat .git/refs/tags/$_tag
+}
+
+# Generate a commit using the text specified to make it unique and the tree
+# named by the tag specified.
+unique_commit()
+{
+   _text=$1
+_tree=$2
+   shift 2
+   echo $_text | git-commit-tree $(tag $_tree) "$@"
+}
+
+# Save the output of a command into the tag specified. Prepend
+# a substitution script for the tag onto the front of $sed_script
+save_tag()
+{
+   _tag=$1 
+   [ -n "$_tag" ] || error "usage: save_tag tag commit-args ..."
+   shift 1
+   "$@" >.git/refs/tags/$_tag
+   sed_script="s/$(tag $_tag)/$_tag/g${sed_script+;}$sed_script"
+}
+
+# Replace unhelpful sha1 hashses with their symbolic equivalents 
+entag()
+{
+   sed "$sed_script"
+}
+
+# Execute a command after first saving, then setting the GIT_AUTHOR_EMAIL
+# tag to a specified value. Restore the original value on return.
+as_author()
+{
+   _author=$1
+   shift 1
+_save=$GIT_AUTHOR_EMAIL
+
+   export GIT_AUTHOR_EMAIL="$_author"
+   "$@"
+export GIT_AUTHOR_EMAIL="$_save"
+}
+
+commit_date()
+{
+_commit=$1
+   git-cat-file commit $_commit | sed -n "s/^committer .*> \([0-9]*\) 
.*/\1/p" 
+}
+
+on_committer_date()
+{
+_date=$1
+shift 1
+GIT_COMMITTER_DATE=$_date "$@"
+}
+
+# Execute a command and suppress any error output.
+hide_error()
+{
+   "$@" 2>/dev/null
+}
+
+check_output()
+{
+   _name=$1
+   shift 1
+   if eval "$*" | entag > $_name.actual
+   then
+   diff $_name.expected $_name.actual
+   else
+   return 1;
+   fi
+}
+
+# Turn a reasonable test description into a reasonable test name.
+# All alphanums translated into -'s which are then compressed and stripped
+# from front and back.
+name_from_description()
+{
+tr "'" '-' | tr '[EMAIL PROTECTED]&*()_+={}[]|\;:"<>,/? ' '-' | tr -s 
'-' | tr '[A-Z]' '[a-z]' | sed "s/^-*//;s/-*\$//"
+}
+
+
+# Execute the test described by the first argument, by eval'ing
+# command line specified in the 2nd argument. Check the status code
+# is zero and that the output matches the stream read from 
+# stdin.
+test_output_expect_success()
+{  
+   _description=$1
+_test=$2
+[ $# -eq 2 ] || error "usage: test_output_expect_success description 
test < $_name.expected
+   test_expect_success "$_description" "check_output $_name \"$_test\"" 
+}
diff --git a/t/t6001-rev-list-merge-order.sh b/t/t6001-rev-list-merge-order.sh
--- a/t/t6001-rev-list-merge-order.sh
+++ b/t/t6001-rev-list-merge-order.sh
@@ -6,117 +6,7 @@
 test_description='Tests git-rev-list --merge-order functionality'
 
 . ./test-lib.sh
-
-#
-# TODO: move the following block (upto --- end ...) into testlib.sh
-#
-[ -d .git/refs/tags ] || mkdir -p .git/refs/tags
-
-sed_script="";
-
-# Answer the sha1 has associated with the tag. The tag must exist in .git or 
.git/refs/tags
-tag()
-{
-   _tag=$1
-   [ -f .git/refs/tags/$_tag ] || error "tag: \"$_tag\" does not exist"
-   cat .git/refs/tags/$_tag
-}
-
-# Generate a commit using the text specified to make it unique and the tree
-# named by the tag specified.
-unique_commit()
-{
-   _text=$1
-_tree=$2
-   shift 2
-   echo $_text | git-commit-tree $(tag $_tree) "$@"
-}
-
-# Save the output of a command into the tag specified. Prepend
-# a substitution script for the tag onto the front of $sed_script
-save_tag()
-{
-   _tag=$1 
-   [ -n "$_tag" ] || error "usage: save_tag tag commit-args ..."
-   shift 1
-   "$@" >.git/refs/tags/$_tag
-   sed_script="s/$(tag $_tag)/$_tag

[PATCH 1/2] Add a t/t6001 test case for a --merge-order bug

[Jon Seymour]

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] Temporary fixup to rev-list.c to restore expected order of 
arguments presented to --merge-order sort.
[PATCH 2/6] Swap order of insert_by_date arguments
[PATCH 3/6] Introduce struct rev_list_fns to rev-list.c to reduce amount of 
conditional processing.
[PATCH 4/6] Add a topological sort procedure to commit.c [rev 4]
[PATCH 5/6] Introduce --topo-order switch to git-rev-list
[PATCH 6/6] Change gitk so that it uses --topo-order rather than --merge-order

and 

[PATCH 1/3] Factor out useful test case infrastructure from t/t6001... into 
t/t6000-lib.sh
[PATCH 2/3] Introduce unit tests for git-rev-list --bisect
[PATCH 3/3] Change the sed seperator in t/t6000-lib.sh.

A subsequent patch will fix the problem.
---

 t/t6001-rev-list-merge-order.sh |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

3c04d86fbc9310e823a6a46ac7bf295fda57c7b7
diff --git a/t/t6001-rev-list-merge-order.sh b/t/t6001-rev-list-merge-order.sh
--- a/t/t6001-rev-list-merge-order.sh
+++ b/t/t6001-rev-list-merge-order.sh
@@ -438,6 +438,26 @@ a2
 a1
 EOF
 
+test_output_expect_success "--merge-order a4 l3" "git-rev-list --merge-order 
a4 l3" <http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] Fixes a problem with --merge-order A B (A is linear descendent of a merge B)

[Jon Seymour]

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/epoch.c
@@ -612,7 +612,7 @@ int sort_list_in_merge_order(struct comm
while (reversed) {
struct commit * next = pop_commit(&reversed);
 
-   if (!(next->object.flags & VISITED)) {
+   if (!(next->object.flags & VISITED) && next!=base) {
sort_first_epoch(next, &stack);
if (reversed) {
/*

-
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

[PATCH 3/3] Change the sed seperator in t/t6000-lib.sh.

[Jon Seymour]

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 to the code that was moved from t/t6001... into t/t6000-lib.sh
---

 t/t6000-lib.sh |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

ca2833542fed15371f9acde4c1bdeb6bc53046c0
diff --git a/t/t6000-lib.sh b/t/t6000-lib.sh
--- a/t/t6000-lib.sh
+++ b/t/t6000-lib.sh
@@ -28,7 +28,9 @@ save_tag()
[ -n "$_tag" ] || error "usage: save_tag tag commit-args ..."
shift 1
"$@" >.git/refs/tags/$_tag
-   sed_script="s/$(tag $_tag)/$_tag/g${sed_script+;}$sed_script"
+
+   sed_script="s/$(tag $_tag)/$_tag/g
+$sed_script"
 }
 
 # Replace unhelpful sha1 hashses with their symbolic equivalents 

-
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

[PATCH 2/3] Introduce unit tests for git-rev-list --bisect

[Jon Seymour]

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/t6002-rev-list-bisect.sh

98721c0ec0eef1e96c51848c528da0a793fe07a5
diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh
new file mode 100755
--- /dev/null
+++ b/t/t6002-rev-list-bisect.sh
@@ -0,0 +1,247 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Jon Seymour
+#
+test_description='Tests git-rev-list --bisect functionality'
+
+. ./test-lib.sh
+. ../t6000-lib.sh
+
+bc_expr()
+{
+bc <=0) { return x; } else { return -x; } }
+define floor(x) { save=scale; scale=0; result=x/1; scale=save; return result; }
+$*
+EOF
+}
+
+# usage: test_bisection max-diff bisect-option head ^prune...
+#
+# e.g. test_bisection 1 --bisect l1 ^l0
+#
+test_bisection_diff()
+{
+   _max_diff=$1
+   _bisect_option=$2
+   shift 2
+   _bisection=$(git-rev-list $_bisect_option "$@")
+   _list_size=$(git-rev-list "$@" | wc -l)
+_head=$1
+   shift 1
+   _bisection_size=$(git-rev-list $_bisection "$@" | wc -l)
+   [ -n "$_list_size" -a -n "$_bisection_size" ] || error 
"test_bisection_diff failed"
+   test_expect_success "bisection diff $_bisect_option $_head $* <= 
$_max_diff" "[ $(bc_expr "floor(abs($_list_size/2)-$_bisection_size)") -le 
$_max_diff ]"
+}
+
+date >path0
+git-update-cache --add path0
+save_tag tree git-write-tree
+on_committer_date "1971-08-16 00:00:00" hide_error save_tag root unique_commit 
root tree
+on_committer_date "1971-08-16 00:00:01" save_tag l0 unique_commit l0 tree -p 
root
+on_committer_date "1971-08-16 00:00:02" save_tag l1 unique_commit l1 tree -p l0
+on_committer_date "1971-08-16 00:00:03" save_tag l2 unique_commit l2 tree -p l1
+on_committer_date "1971-08-16 00:00:04" save_tag a0 unique_commit a0 tree -p l2
+on_committer_date "1971-08-16 00:00:05" save_tag a1 unique_commit a1 tree -p a0
+on_committer_date "1971-08-16 00:00:06" save_tag b1 unique_commit b1 tree -p a0
+on_committer_date "1971-08-16 00:00:07" save_tag c1 unique_commit c1 tree -p b1
+on_committer_date "1971-08-16 00:00:08" save_tag b2 unique_commit b2 tree -p b1
+on_committer_date "1971-08-16 00:00:09" save_tag b3 unique_commit b2 tree -p b2
+on_committer_date "1971-08-16 00:00:10" save_tag c2 unique_commit c2 tree -p 
c1 -p b2
+on_committer_date "1971-08-16 00:00:11" save_tag c3 unique_commit c3 tree -p c2
+on_committer_date "1971-08-16 00:00:12" save_tag a2 unique_commit a2 tree -p a1
+on_committer_date "1971-08-16 00:00:13" save_tag a3 unique_commit a3 tree -p a2
+on_committer_date "1971-08-16 00:00:14" save_tag b4 unique_commit b4 tree -p 
b3 -p a3
+on_committer_date "1971-08-16 00:00:15" save_tag a4 unique_commit a4 tree -p 
a3 -p b4 -p c3
+on_committer_date "1971-08-16 00:00:16" save_tag l3 unique_commit l3 tree -p a4
+on_committer_date "1971-08-16 00:00:17" save_tag l4 unique_commit l4 tree -p l3
+on_committer_date "1971-08-16 00:00:18" save_tag l5 unique_commit l5 tree -p l4
+tag l5 > .git/HEAD
+
+
+# E
+#/ \
+#   e1  |
+#   |   |
+#   e2  |
+#   |   |
+#   e3  |
+#   |   |
+#   e4  |
+#   |   |
+#   |   f1
+#   |   |
+#   |   f2
+#   |   |
+#   |   f3
+#   |   |
+#   |   f4
+#   |   |
+#   e5  |
+#   |   |
+#   e6  |
+#   |   |
+#   e7  |
+#   |   |
+#   e8  |
+#\ /
+# F
+
+
+on_committer_date "1971-08-16 00:00:00" hide_error save_tag F unique_commit F 
tree
+on_committer_date "1971-08-16 00:00:01" save_tag e8 unique_commit e8 tree -p F
+on_committer_date "1971-08-16 00:00:02" save_tag e7 unique_commit e7 tree -p e8
+on_committer_date "1971-08-16 00:00:03" save_tag e6 unique_commit e6 tree -p e7
+on_committer_date "1971-08-16 00:00:04" save_tag e5 unique_commit e5 tree -p e6
+on_committer_date "1971-08-16 00:00:05" save_tag f4 unique_commit f4 tree -p F
+on_committer_date "1971-08-16 00:00:06" save_tag f3 unique_commit f3 tree -p f4
+on_committer_date "1971-08-16 00:00:07" save_tag f2 unique_commit f2 tree -p f3
+on_committer_date "1971-08-16 00:00:08" save_tag f1 unique_commit f1 tree -p f2
+on_committer_date "1971-08-16 00:00:09" save_tag e4 unique_commit e4 tree -p e5
+on_committer_date "1971-08-16 00:00:10" save_tag e3 unique_commit e3 tree -p e4
+on_committer_date "1971-08-16 00:00:11" save_tag e2 unique_commit e2 tree -p e3
+on_committer_date "1971-08-16 00:00:12" save_tag e1 unique_commit e1 tree -p e2
+on_committer_date "1971-08-16 00:00:1

[PATCH 1/3] Factor out useful test case infrastructure from t/t6001... into t/t6000-lib.sh

[Jon Seymour]

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 introduces tests for the git-rev-list --bisect functionality 
and includes Mark Allen's sed separator patch.

The patches included are:

[PATCH 1/3] Factor out useful test case infrastructure from t/t6001... into 
t/t6000-lib.sh
[PATCH 2/3] Introduce unit tests for git-rev-list --bisect
[PATCH 3/3] Change the sed seperator in t/t6000-lib.sh.
---

 t/t6000-lib.sh  |  105 +
 t/t6001-rev-list-merge-order.sh |  112 ---
 2 files changed, 106 insertions(+), 111 deletions(-)
 create mode 100644 t/t6000-lib.sh

a6686d8335905d55ef6cf996af1d3eb229ad955c
diff --git a/t/t6000-lib.sh b/t/t6000-lib.sh
new file mode 100644
--- /dev/null
+++ b/t/t6000-lib.sh
@@ -0,0 +1,105 @@
+[ -d .git/refs/tags ] || mkdir -p .git/refs/tags
+
+sed_script="";
+
+# Answer the sha1 has associated with the tag. The tag must exist in .git or 
.git/refs/tags
+tag()
+{
+   _tag=$1
+   [ -f .git/refs/tags/$_tag ] || error "tag: \"$_tag\" does not exist"
+   cat .git/refs/tags/$_tag
+}
+
+# Generate a commit using the text specified to make it unique and the tree
+# named by the tag specified.
+unique_commit()
+{
+   _text=$1
+_tree=$2
+   shift 2
+   echo $_text | git-commit-tree $(tag $_tree) "$@"
+}
+
+# Save the output of a command into the tag specified. Prepend
+# a substitution script for the tag onto the front of $sed_script
+save_tag()
+{
+   _tag=$1 
+   [ -n "$_tag" ] || error "usage: save_tag tag commit-args ..."
+   shift 1
+   "$@" >.git/refs/tags/$_tag
+   sed_script="s/$(tag $_tag)/$_tag/g${sed_script+;}$sed_script"
+}
+
+# Replace unhelpful sha1 hashses with their symbolic equivalents 
+entag()
+{
+   sed "$sed_script"
+}
+
+# Execute a command after first saving, then setting the GIT_AUTHOR_EMAIL
+# tag to a specified value. Restore the original value on return.
+as_author()
+{
+   _author=$1
+   shift 1
+_save=$GIT_AUTHOR_EMAIL
+
+   export GIT_AUTHOR_EMAIL="$_author"
+   "$@"
+export GIT_AUTHOR_EMAIL="$_save"
+}
+
+commit_date()
+{
+_commit=$1
+   git-cat-file commit $_commit | sed -n "s/^committer .*> \([0-9]*\) 
.*/\1/p" 
+}
+
+on_committer_date()
+{
+_date=$1
+shift 1
+GIT_COMMITTER_DATE=$_date "$@"
+}
+
+# Execute a command and suppress any error output.
+hide_error()
+{
+   "$@" 2>/dev/null
+}
+
+check_output()
+{
+   _name=$1
+   shift 1
+   if eval "$*" | entag > $_name.actual
+   then
+   diff $_name.expected $_name.actual
+   else
+   return 1;
+   fi
+}
+
+# Turn a reasonable test description into a reasonable test name.
+# All alphanums translated into -'s which are then compressed and stripped
+# from front and back.
+name_from_description()
+{
+tr "'" '-' | tr '[EMAIL PROTECTED]&*()_+={}[]|\;:"<>,/? ' '-' | tr -s 
'-' | tr '[A-Z]' '[a-z]' | sed "s/^-*//;s/-*\$//"
+}
+
+
+# Execute the test described by the first argument, by eval'ing
+# command line specified in the 2nd argument. Check the status code
+# is zero and that the output matches the stream read from 
+# stdin.
+test_output_expect_success()
+{  
+   _description=$1
+_test=$2
+[ $# -eq 2 ] || error "usage: test_output_expect_success description 
test < $_name.expected
+   test_expect_success "$_description" "check_output $_name \"$_test\"" 
+}
diff --git a/t/t6001-rev-list-merge-order.sh b/t/t6001-rev-list-merge-order.sh
--- a/t/t6001-rev-list-merge-order.sh
+++ b/t/t6001-rev-list-merge-order.sh
@@ -6,117 +6,7 @@
 test_description='Tests git-rev-list --merge-order functionality'
 
 . ./test-lib.sh
-
-#
-# TODO: move the following block (upto --- end ...) into testlib.sh
-#
-[ -d .git/refs/tags ] || mkdir -p .git/refs/tags
-
-sed_script="";
-
-# Answer the sha1 has associated with the tag. The tag must exist in .git or 
.git/refs/tags
-tag()
-{
-   _tag=$1
-   [ -f .git/refs/tags/$_tag ] || error "tag: \"$_tag\" does not exist"
-   cat .git/refs/tags/$_tag
-}
-
-# Generate a commit using the text specified to make it unique and the tree
-# named by the tag specified.
-unique_commit()
-{
-   _text=$1
-_tree=$2
-   shift 2
-   echo $_text | git-commit-tree $(tag $_tree) "$@"
-}
-
-# Save the

[PATCH] Tidy up - slight simplification of rev-list.c

[Jon Seymour]

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 thing from a
readability point of view. Let me know if you disagree.
---

 rev-list.c |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)

34a034b978c6b946fafdf41b42c5f67ee9c94599
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -78,19 +78,15 @@ static void show_commit(struct commit *c
 
 static int filter_commit(struct commit * commit)
 {
-   if (merge_order && stop_traversal && commit->object.flags & BOUNDARY)
+   if (stop_traversal && (commit->object.flags & BOUNDARY))
return STOP;
if (commit->object.flags & (UNINTERESTING|SHOWN))
return CONTINUE;
if (min_age != -1 && (commit->date > min_age))
return CONTINUE;
if (max_age != -1 && (commit->date < max_age)) {
-   if (!merge_order)
-   return STOP;
-   else {
-   stop_traversal = 1;
-   return CONTINUE;
-   }
+   stop_traversal=1;
+   return merge_order?CONTINUE:STOP;
}
if (max_count != -1 && !max_count--)
return STOP;

-
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

[PATCH 3/6] Introduce struct rev_list_fns to rev-list.c to reduce amount of conditional processing.

[Jon Seymour]

Per a suggestion from Linus, I have introduced the rev_list_fns structure into
rev-list.c

The intent of this change is to make use of a strategy pattern to configure 
the behaviour of git-rev-list and so help limit the ever-increasing 
proliferation of boolean switches throughout the body of the 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 <[EMAIL PROTECTED]>
---

 Documentation/git-rev-list.txt |2 +
 rev-list.c |   54 +++-
 2 files changed, 38 insertions(+), 18 deletions(-)

1ecc1f5936fb35d2ea8e7aef2d97643a78fe1069
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -57,7 +57,7 @@ Commits marked with (^) are not parents 
 These "breaks" represent necessary discontinuities implied by trying to
 represent an arbtirary DAG in a linear form.
 
-*--show-breaks* is only valid if *--merge-order* is also specified.
+*--show-breaks* implies **-merge-order*.
 
 Author
 --
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -39,6 +39,12 @@ static int merge_order = 0;
 static int show_breaks = 0;
 static int stop_traversal = 0;
 
+struct rev_list_fns {
+   struct commit_list * (*insert)(struct commit *, struct commit_list **);
+   struct commit_list * (*limit)(struct commit_list *);
+   void (*process)(struct commit_list *);
+};
+
 static void show_commit(struct commit *commit)
 {
commit->object.flags |= SHOWN;
@@ -410,9 +416,30 @@ static struct commit *get_commit_referen
die("%s is unknown object", name);
 }
 
+static void merge_order_sort(struct commit_list * list)
+{
+   if (sort_list_in_merge_order(list, &process_commit))
+   die("commit graph traversal failed");
+}
+
+struct rev_list_fns default_fns = {
+   &insert_by_date,
+   &limit_list,
+&show_commit_list
+};
+
+struct rev_list_fns merge_order_fns = {
+   &commit_list_insert,
+   NULL,
+   &merge_order_sort
+};
+
 int main(int argc, char **argv)
 {
struct commit_list *list = NULL;
+   struct commit_list *sorted = NULL;
+   struct commit_list **list_tail = &list;
+   struct rev_list_fns * fns = &default_fns;
int i, limited = 0;
 
for (i = 1 ; i < argc; i++) {
@@ -468,6 +495,7 @@ int main(int argc, char **argv)
}
if (!strcmp(arg, "--show-breaks")) {
show_breaks = 1;
+   merge_order = 1;
continue;
}
 
@@ -477,26 +505,18 @@ int main(int argc, char **argv)
arg++;
limited = 1;
}
-   if (show_breaks && !merge_order)
-   usage(rev_list_usage);
commit = get_commit_reference(arg, flags);
if (!commit)
continue;
-   if (!merge_order) 
-   insert_by_date(commit, &list);
-   else 
-   commit_list_insert(commit, &list);
+   list_tail = &commit_list_insert(commit, list_tail)->next;
}
-
-   if (!merge_order) { 
-   if (limited)
-   list = limit_list(list);
-   show_commit_list(list);
-   } else {
-   if (sort_list_in_merge_order(list, &process_commit)) {
- die("merge order sort failed\n");
-   }
-   }
-
+   if (merge_order)
+   fns=&merge_order_fns;
+   while (list)
+   (*(fns->insert))(pop_commit(&list), &sorted);
+   list=sorted;
+   if (limited && fns->limit)
+   list = (*(fns->limit))(list);
+   (*(fns->process))(list);
return 0;
 }

-
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

[PATCH 2/6] Swap order of insert_by_date arguments

[Jon Seymour]

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 +-
 epoch.c|4 ++--
 rev-list.c |2 +-
 4 files changed, 12 insertions(+), 8 deletions(-)

486d4dee9772a59b955574951e8d4946b75cf9fa
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -147,7 +147,7 @@ void free_commit_list(struct commit_list
}
 }
 
-void insert_by_date(struct commit_list **list, struct commit *item)
+struct commit_list * insert_by_date(struct commit *item, struct commit_list 
**list)
 {
struct commit_list **pp = list;
struct commit_list *p;
@@ -157,7 +157,7 @@ void insert_by_date(struct commit_list *
}
pp = &p->next;
}
-   commit_list_insert(item, pp);
+   return commit_list_insert(item, pp);
 }
 

@@ -165,7 +165,7 @@ void sort_by_date(struct commit_list **l
 {
struct commit_list *ret = NULL;
while (*list) {
-   insert_by_date(&ret, (*list)->item);
+   insert_by_date((*list)->item, &ret);
*list = (*list)->next;
}
*list = ret;
@@ -186,7 +186,7 @@ struct commit *pop_most_recent_commit(st
parse_commit(commit);
if (!(commit->object.flags & mark)) {
commit->object.flags |= mark;
-   insert_by_date(list, commit);
+   insert_by_date(commit, list);
}
parents = parents->next;
}
diff --git a/commit.h b/commit.h
--- a/commit.h
+++ b/commit.h
@@ -44,7 +44,11 @@ enum cmit_fmt {
 extern enum cmit_fmt get_commit_format(const char *arg);
 extern unsigned long pretty_print_commit(enum cmit_fmt fmt, const char *msg, 
unsigned long len, char *buf, unsigned long space);
 
-void insert_by_date(struct commit_list **list, struct commit *item);
+/*
+ * Inserts item into the list specified in most recent commit date first order.
+ * A pointer to the most recently inserted item is returned.
+ */
+struct commit_list * insert_by_date(struct commit *item, struct commit_list 
**list);
 
 /** Removes the first commit from a list sorted by date, and adds all
  * of its parents.
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -255,11 +255,11 @@ static int find_base_for_list(struct com
 
if (!parent_node) {
parent_node = new_mass_counter(parent, 
&distribution);
-   insert_by_date(&pending, parent);
+   insert_by_date(parent, &pending);
commit_list_insert(parent, &cleaner);
} else {
if (!compare(&parent_node->pending, 
get_zero()))
-   insert_by_date(&pending, 
parent);
+   insert_by_date(parent, 
&pending);
add(&parent_node->pending, 
&parent_node->pending, &distribution);
}
}
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -483,7 +483,7 @@ int main(int argc, char **argv)
if (!commit)
continue;
if (!merge_order) 
-   insert_by_date(&list, commit);
+   insert_by_date(commit, &list);
else 
commit_list_insert(commit, &list);
}

-
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

[PATCH 1/6] Temporary fixup to rev-list.c to restore expected order of arguments presented to --merge-order sort.

[Jon Seymour]

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 changed, 4 insertions(+), 1 deletions(-)

c63fe4678d33db15db076606f7a133868e91f1bc
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -482,7 +482,10 @@ int main(int argc, char **argv)
commit = get_commit_reference(arg, flags);
if (!commit)
continue;
-   insert_by_date(&list, commit);
+   if (!merge_order) 
+   insert_by_date(&list, commit);
+   else 
+   commit_list_insert(commit, &list);
}
 
if (!merge_order) { 

-
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

[PATCH 4/6] Add a topological sort procedure to commit.c [rev 4]

[Jon Seymour]

This patch introduces an in-place topological sort procedure to commit.c.

Given a list of commits, sort_in_topological_order() will perform an in-place
topological sort of that list.

The invariant that applies to the resulting list is:

   a reachable from b => ord(b) < ord(a)

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 no observable consequences since nothing
in this patch calls it. A future patch will use this algorithm to provide
support for a --topo-order flag.

This patch is a complete replacement for earlier revisions of this patch.

[rev 2]
  * incorporates Junio's questions/comments as commentary,
  * adds object.util save/restore functionality so that no
assumption is made about the pre-existing state of object.util
upon entry to the procedure.
[rev 3]
  * removed object.util save/restore
  * added more documentation to header about pre-conditions
[rev 4]
  * re-applied rev 3 to new patch series - no other change
---

 commit.c |  107 ++
 commit.h |   13 
 2 files changed, 120 insertions(+), 0 deletions(-)

f80e897fd36a77425cdec24af48746706d7a2e74
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -3,6 +3,22 @@
 #include "commit.h"
 #include "cache.h"
 
+struct sort_node
+{
+   /*
+ * the number of children of the associated commit
+ * that also occur in the list being sorted.
+ */
+   unsigned int indegree;
+
+   /*
+ * reference to original list item that we will re-use
+ * on output.
+ */
+   struct commit_list * list_item;
+
+};
+
 const char *commit_type = "commit";
 
 enum cmit_fmt get_commit_format(const char *arg)
@@ -346,3 +362,94 @@ int count_parents(struct commit * commit
 return count;
 }
 
+/*
+ * Performs an in-place topological sort on the list supplied.
+ */
+void sort_in_topological_order(struct commit_list ** list)
+{
+   struct commit_list * next = *list;
+   struct commit_list * work = NULL;
+   struct commit_list ** pptr = list;
+   struct sort_node * nodes;
+   struct sort_node * next_nodes;
+   int count = 0;
+
+   /* determine the size of the list */
+   while (next) {
+   next = next->next;
+   count++;
+   }
+   /* allocate an array to help sort the list */
+   nodes = xcalloc(count, sizeof(*nodes));
+   /* link the list to the array */
+   next_nodes = nodes;
+   next=*list;
+   while (next) {
+   next_nodes->list_item = next;
+   next->item->object.util = next_nodes;
+   next_nodes++;
+   next = next->next;
+   }
+   /* update the indegree */
+   next=*list;
+   while (next) {
+   struct commit_list * parents = next->item->parents;
+   while (parents) {
+   struct commit * parent=parents->item;
+   struct sort_node * pn = (struct sort_node 
*)parent->object.util;
+   
+   if (pn)
+   pn->indegree++;
+   parents=parents->next;
+   }
+   next=next->next;
+   }
+   /* 
+ * find the tips
+ *
+ * tips are nodes not reachable from any other node in the list 
+ * 
+ * the tips serve as a starting set for the work queue.
+ */
+   next=*list;
+   while (next) {
+   struct sort_node * node = (struct sort_node 
*)next->item->object.util;
+
+   if (node->indegree == 0) {
+   commit_list_insert(next->item, &work);
+   }
+   next=next->next;
+   }
+   /* process the list in topological order */
+   while (work) {
+   struct commit * work_item = pop_commit(&work);
+   struct sort_node * work_node = (struct sort_node 
*)work_item->object.util;
+   struct commit_list * parents = work_item->parents;
+
+   while (parents) {
+   struct commit * parent=parents->item;
+   struct sort_node * pn = (struct sort_node 
*)parent->object.util;
+   
+   if (pn) {
+   /* 
+* parents are only enqueued for emission 
+ * when all their children have been emitted 
thereby
+ * guaranteeing topological order.
+   

[PATCH 6/6] Change gitk so that it uses --topo-order rather than --merge-order

[Jon Seymour]

This change is made so that gitk --all produces the same result for
every user irrespective of whether git-rev-parse --all produces
the same result for every user. By using --topo-order rather than
--merge-order this can be guaranteed and the existing (non-timestamp dependent)
behaviour of --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
start list, whereas git-rev-list --merge-order produces an order that is 
deliberately
sensitive to the order of the start list.

Linus wants gitk --all to behave the same way, irrespective of what order
git-rev-parse --all produces its output. I want --merge-order to keep its
existing behaviour, so we agreed on this compromise whereby gitk uses
--topo-order rather than --merge-order by default.

My understanding of your code is that you only expect a minimal topological 
ordering
guarantee and the ordering produced by --topo-order should be sufficient
for your needs - that is, you don't rely on the other aspect of the
--merge-order invariant.

I'll leave it to you and Linus to decide how you want to manage the merge 
between
your HEAD and Linus'.
---

 gitk |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

ff2ca5764029d451f2a728845dad12c4e950fae1
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -37,7 +37,7 @@ proc getcommits {rargs} {
set parsed_args $rargs
 }
 if [catch {
-   set commfd [open "|git-rev-list --header --merge-order $parsed_args" r]
+   set commfd [open "|git-rev-list --header --topo-order $parsed_args" r]
 } err] {
puts stderr "Error executing git-rev-list: $err"
exit 1

-
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

[PATCH 5/6] Introduce --topo-order switch to git-rev-list

[Jon Seymour]

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-by: Jon Seymour <[EMAIL PROTECTED]>
---

 Documentation/git-rev-list.txt |9 +++--
 rev-list.c |   27 +--
 2 files changed, 32 insertions(+), 4 deletions(-)

8829e9cd41c15ecc39214d76e117c28cfc8757ce
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -9,13 +9,15 @@ git-rev-list - Lists commit objects in r
 
 SYNOPSIS
 
-'git-rev-list' [ *--max-count*=number ] [ *--max-age*=timestamp ] [ 
*--min-age*=timestamp ] [ *--merge-order* [ *--show-breaks* ] ] 
+'git-rev-list' [ *--max-count*=number ] [ *--max-age*=timestamp ] [ 
*--min-age*=timestamp ] [ *--merge-order* ] [ *--show-breaks* ] [ 
*--topo-order* ] ... ^...
 
 DESCRIPTION
 ---
 Lists commit objects in reverse chronological order starting at the
 given commit, taking ancestry relationship into account.  This is
-useful to produce human-readable log output.
+useful to produce human-readable log output. If prune points are specified
+with ^... arguments, the output will not include any commits reachable
+from (and including) the prune points.
 
 If *--merge-order* is specified, the commit history is decomposed into a
 unique sequence of minimal, non-linear epochs and maximal, linear epochs.
@@ -59,6 +61,9 @@ represent an arbtirary DAG in a linear f
 
 *--show-breaks* implies **-merge-order*.
 
+If *--topo-order* is specified, the commit history is sorted in a topological
+order that is weaker than the topological order generated by *--merge-order*.
+
 Author
 --
 Written by Linus Torvalds <[EMAIL PROTECTED]>
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -20,6 +20,7 @@ static const char rev_list_usage[] =
  "  --unpacked\n"
  "  --header\n"
  "  --pretty\n"
+ "  --topo-order\n"
  "  --merge-order [ --show-breaks ]";
 
 static int unpacked = 0;
@@ -38,10 +39,12 @@ static enum cmit_fmt commit_format = CMI
 static int merge_order = 0;
 static int show_breaks = 0;
 static int stop_traversal = 0;
+static int topo_order = 0;
 
 struct rev_list_fns {
struct commit_list * (*insert)(struct commit *, struct commit_list **);
struct commit_list * (*limit)(struct commit_list *);
+   void (*post_limit_sort)(struct commit_list **);
void (*process)(struct commit_list *);
 };
 
@@ -425,12 +428,21 @@ static void merge_order_sort(struct comm
 struct rev_list_fns default_fns = {
&insert_by_date,
&limit_list,
-&show_commit_list
+   NULL,
+   &show_commit_list
+};
+
+struct rev_list_fns topo_order_fns = {
+   &insert_by_date,
+   &limit_list,
+   &sort_in_topological_order,
+   &show_commit_list
 };
 
 struct rev_list_fns merge_order_fns = {
&commit_list_insert,
NULL,
+   NULL,
&merge_order_sort
 };
 
@@ -439,7 +451,7 @@ int main(int argc, char **argv)
struct commit_list *list = NULL;
struct commit_list *sorted = NULL;
struct commit_list **list_tail = &list;
-   struct rev_list_fns * fns = &default_fns;
+   struct rev_list_fns * fns = NULL;
int i, limited = 0;
 
for (i = 1 ; i < argc; i++) {
@@ -498,6 +510,11 @@ int main(int argc, char **argv)
merge_order = 1;
continue;
}
+   if (!strcmp(arg, "--topo-order")) {
+   topo_order = 1;
+   limited=1;
+   continue;
+   }
 
flags = 0;
if (*arg == '^') {
@@ -512,11 +529,17 @@ int main(int argc, char **argv)
}
if (merge_order)
fns=&merge_order_fns;
+   else if (topo_order)
+   fns=&topo_order_fns;
+   else
+   fns=&default_fns;
while (list)
(*(fns->insert))(pop_commit(&list), &sorted);
list=sorted;
if (limited && fns->limit)
list = (*(fns->limit))(list);
+   if (fns->post_limit_sort)
+   (*(fns->post_limit_sort))(&list);
(*(fns->process))(list);
return 0;
 }

-
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

Re: [PATCH] Restore expected list order for --merge-order switch

[Jon Seymour]

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
> breaks in the t/t6001 unit tests.
> 
> This change restores the order in which start points are presented to the
> the merge-order sort algorithm (but leaves the order unchanged from
> the immediately preceding behaviour for non --merge-order sorts).
> 
> The order in which arguments are presented to the merge-order
> sort algorithm is significant, since left-most arguments
> are expected to sort last so as to be consistent with
> how left-most parents sort.
> 
> Signed-off-by: Jon Seymour <[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

Re: [PATCH] Add script for patch submission via e-mail.

[Jon Seymour]

On 7/6/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
> 
> PB> Any reason why this was not applied? It appears kind of cool.
> 
> FYI, the one in <[EMAIL PROTECTED]> is
> newer than what you quoted.
> 
> One thing _I_ am unhappy about what it does is that it does not
> try to be intelligent about merges (I haven't tried the script
> on a merged head myself).

I am not completely sure this is really a problem. I would presume
that the project lead doesn't really need to use
git-format-patch-script and the individual developer should probably
rebase on the latest head which is either done by trivially reapplying
the patches in sequence automatically or reapplying the patches in
sequence with some edits to fix any conflicts that have arisen.

So, it 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 patches that spans a merge commit.

jon.
-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
-
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

Re: [PATCH] Add script for patch submission via e-mail.

[Jon Seymour]

On 7/5/05, Petr Baudis <[EMAIL PROTECTED]> wrote:
> 
> Any reason why this was not applied? It appears kind of cool. Well, I
> will probably take it and extend cg-mkpatch with it so I don't need it
> in Git, but I'm so altruistic and want to bring at least a bit of light
> 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

Re: [PATCH] Fixlet for argument parsing in rev-list.

[Jon Seymour]

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 <[EMAIL PROTECTED]>
> ---
> 
>  rev-list.c |2 +-
>  1 file changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/rev-list.c b/rev-list.c
> --- a/rev-list.c
> +++ b/rev-list.c
> @@ -462,7 +462,7 @@ int main(int argc, char **argv)
> limited = 1;
> continue;
> }
> -   if (!strncmp(arg, "--merge-order", 13)) {
> +   if (!strcmp(arg, "--merge-order")) {
> merge_order = 1;
> continue;
> }
> 
> 
> 


-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
-
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

[PATCH] Restore expected list order for --merge-order switch

[Jon Seymour]

A recent change to rev-list altered the order in which start points
are presented to the merge-order sort algorithm. This caused
breaks in the t/t6001 unit tests.

This change restores the order in which start points are presented to the
the merge-order sort algorithm (but leaves the order unchanged from
the immediately preceding behaviour for non --merge-order sorts).

The order in which arguments are presented to the merge-order
sort algorithm is significant, since left-most arguments
are expected to sort last so as to be consistent with
how left-most parents sort.

Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---

 rev-list.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

ed4451af196ea31ec0c6c7f663290a9b325482cd
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -482,7 +482,10 @@ int main(int argc, char **argv)
commit = get_commit_reference(arg, flags);
if (!commit)
continue;
-   insert_by_date(&list, commit);
+   if (!merge_order) 
+   insert_by_date(&list, commit);
+   else
+   commit_list_insert(commit, &list);
}
 
if (!merge_order) { 

-
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

[PATCH] Fixup t/t5300 unit tests broken by 5f3de58ff85c49620ae2a1722d8d4d37c881a054

[Jon Seymour]

This patch fixes up the t/t5300 unit tests which were broken by the changes in:

Make the name of a pack-file depend on the objects packed there-in.

Signed-off-by: Jon Seymour <[EMAIL PROTECTED]>
---

 t/t5300-pack-object.sh |   30 +++---
 1 files changed, 15 insertions(+), 15 deletions(-)

1bd90884e1a91e2f2e84898703c79cb9c8db0572
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -35,18 +35,18 @@ test_expect_success \
 
 test_expect_success \
 'pack without delta' \
-'git-pack-objects --window=0 test-1 http://vger.kernel.org/majordomo-info.html

Re: First web interface and service API draft

[Jon Seymour]

> >
> > >From the point of view of a specification, though, I think it would be
> > useful to focus on an XML content model rather than the details of one
> > particular HTML model - get the XML model right and you can do
> > whatever you like with the HTML model at any time after that.
>
> Actually I think the order is get the C content model right (done), get
> the Python object model right (in flux), produce an appropriate XML
> model.

Mmm.. I am not sure that a Python model is logically a pre-requisite
to the XML model nor that the ideal C API model is complete - we still
don't have a libgit, for example.  For an XML model we can get by
pretty well with the data model as it is - and an XML model really
shouldn't be dependent on any particular API or programming language.

Certainly, though, an XML model isn't a pre-requisite to a Python
model. Though it might be a pre-req to a SOAP model :-).

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

Re: First web interface and service API draft

[Jon Seymour]

On 4/22/05, Petr Baudis <[EMAIL PROTECTED]> wrote:
> Dear diary, on Fri, Apr 22, 2005 at 01:34:45PM CEST, I got a letter
> where Jon Seymour <[EMAIL PROTECTED]> told me that...
> > On 4/22/05, Christian Meder <[EMAIL PROTECTED]> wrote:
> > >
> > > Comments ? Ideas ? Other feedback ?
> > >
> >
> > I'd suggest serving XML rather than HTML and using client side XSLT to
> > transform it into HTML. ...
> 
> Why "rather than"? Why not "in addition to"?
> 
> You just append either .html or .xml, based on what you want.
> 

You are right - there is no good reason that an implementation should
not to support both.

>From the point of view of a specification, though, I think it would be
useful to focus on an XML content model rather than the details of one
particular HTML model - get the XML model right and you can do
whatever you like with the HTML model at any time after that.

jon.

On 4/22/05, Petr Baudis <[EMAIL PROTECTED]> wrote:
> Dear diary, on Fri, Apr 22, 2005 at 01:34:45PM CEST, I got a letter
> where Jon Seymour <[EMAIL PROTECTED]> told me that...
> > On 4/22/05, Christian Meder <[EMAIL PROTECTED]> wrote:
> > >
> > > Comments ? Ideas ? Other feedback ?
> > >
> >
> > I'd suggest serving XML rather than HTML and using client side XSLT to
> > transform it into HTML. Client-side XSLT works well in IE 6 and all
> > versions of Firefox, so there is no question that it is a mature
> > technology. Provide a fall back via server transformed HTML if need
> > be, but that is trivial to do once you have the client-side XSLT
> > stylesheets.
> >
> > Serving XML is as easy as serving HTML and gives you a much more
> > flexible outcome.
> 
> Why "rather than"? Why not "in addition to"?
> 
> You just append either .html or .xml, based on what you want.
> 
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> 


-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
-
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

Re: First web interface and service API draft

[Jon Seymour]

On 4/22/05, Christian Meder <[EMAIL PROTECTED]> wrote:
>
> Comments ? Ideas ? Other feedback ?
> 

I'd suggest serving XML rather than HTML and using client side XSLT to
transform it into HTML. Client-side XSLT works well in IE 6 and all
versions of Firefox, so there is no question that it is a mature
technology. Provide a fall back via server transformed HTML if need
be, but that is trivial to do once you have the client-side XSLT
stylesheets.

Serving XML is as easy as serving HTML and gives you a much more
flexible outcome.

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

[RFC] Is there a need for binary bit in cache/tree entries to properly support Cygwin builds of GIT?

[Jon Seymour]

On 4/22/05, lode leroy <[EMAIL PROTECTED]> wrote:
> I wonder if anyone is interested in using git on windows / cygwin.
> It almost compiles out of the box... just this one little thinggy
> that's glibc-specific (struct dirent . d_type)
> 
 
I wonder if a cygwin compile of GIT should be forced to strip CR's
from text files prior to checksum calculations and blob storage.
Otherwise, spurious differences may be introduced into text files that
are somehow munged while checked out in a Windows environment.

There is an argument that this should be done external to the GIT
core, but then every external non-unix tool that interacts with GIT
has to have heuristics to distinguish text from binary and they all
have to have the same heuristics.

So, perhaps there is an argument for using one of the unused "mode"
bits to encode a binary flag and add an option to update-cache that
allows the bit to be flipped if a blob is known to be binary. A cygwin
GIT binary could then be forced to strip CR's from blobs marked as
text, but a unix binary need not change its behaviour.

Regards,

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

Re: wit 0.0.3 - a web interface for git available

[Jon Seymour]

On 4/21/05, Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 20, 2005 at 10:42:53AM +0100, Christoph Hellwig wrote:
> 
> It's working now:
>   http://ehlo.org/~kay/gitweb.pl
> 

Kay + Christian + Ken,

That looks really great!.

One suggestion: when drilling down through the tree it would be nice
if the context of the parents could be dragged along too. So, for
example, when displaying the BLOB, you could display its name because
you have kept enough context around to allow that.

This would also allow you to extend the functionality so that when you
are at the BLOB level you could navigate to a history of changes to
just that BLOB, at least from the point of  view of the commit that
got you there.

Also, have you considered generating pure XML from the database and
relying on XSLT (either at the server, or preferably at the client -
they all do it well these days!) to do the HTML rendering?

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

Re: WARNING! Object DB conversion (was Re: [PATCH] write-tree performance problems)

[Jon Seymour]

> The main point is not about trying different compression
> techniques but that you don't need to compress at all just
> to calculate the hash of some data. (to know if it is
> unchanged for example)
> 

Ah, ok, I didn't understand that there were extra compresses being
performed for that reason. Thanks for the explanation.

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

Re: WARNING! Object DB conversion (was Re: [PATCH] write-tree performance problems)

[Jon Seymour]

On 4/20/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> 
> 
> I converted my git archives (kernel and git itself) to do the SHA1 hash
> _before_ the compression phase.
> 

Linus,
 
 Am I correct to understand that with this change, all the objects in
the database are still being compressed (so no net performance benefit
now), but by doing the SHA1 calculations before compression you are
keeping open the possibility that at some point in the future you may
use a different compression technique (including none at all) for some
or all of the objects?

jon.

[ reposted to list, because list post was bounced because of rich text
formatting ]
-
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

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Jon Seymour]

> I disagree. This already forces you to have two branches (one to pull
> from to get the data, mirroring the remote branch, one for your real
> work) uselessly and needlessly.
> 
> ...
> These naming issues may appear silly but I think they matter big time
> for usability, intuitiveness, and learning curve (I don't want git-pasky
> become another GNU arch).
> 


Not that it is worth that much, but my $0.02 is that Petr is right on
this one. I want something that allows me to get the objects into my
local repository without funking with my working directory.

As a long time CVS user, "git update" would do what I expect it to. I
don't have any pre-conceptions about what "pull" does, so it doesn't
phase me if pull is used for this purpose. However, perhaps pull means
something in some other SCM that would cause confusion for others?

Some alternatives to "pull" are offered: hoard, gather, make-local, download.

Regards,

jon.
-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
-
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

A VFS layer - was: SCM ideas from 2003

[Jon Seymour]

On 19 Apr 2005 08:31:42 +0300, Marc Girod <[EMAIL PROTECTED]> wrote:
> > "KS" == Kevin Smith <[EMAIL PROTECTED]> writes:
> 
> KS> "what's so special about files ?" where the author suggests that
> KS> existing SCM systems are so blinded by the tradition of file
> KS> orientation that they can't see that there might be alternatives.
> 
> Correct: file orientation is eventually a limitation.
> 
> But there are other dimensions to investigate in order to overcome it.
> The issue is to offer a *location* for the possible versions -- not
> only sequential changes but also alternatives.
> 
> A directory may be considered as a namespace.
> Note that there are other cases of 'containers': archives, packages,
> libraries, etc...
> 

Of course, it is not just SCM's that are "blinded" by file orientation
- every other tool (editors, compilters, etc) that we use has this
orientation. An SCM really has to have some notion of file
orientation, at least at the UI level, because every other tool we use
has the same orientation. The ENVY/VisualAge environments tried to
work with a pure class-level orientation and in some ways that was
great, but most developers hated it precisely because it removed the
file orientation and hence their ability to work with their favourite
tools. IBM/OTI saw the light which is why Eclipse is avowedly a
file-oriented platform.

It seems to me that file-orientation is here to stay and it would be
really cool to layer some kind of virtual filesystem over the git
repository so that different trees become transparently accessible via
different branches of a file system, e.g.:
/mnt/gitfs/working  # some kind of writeable
virtual directory over the git cache
/mnt/gitfs/c157067185209b50b350571fe762c2740ea13fc1  # read-only
tree of commit c157...
/mnt/gitfs/5b53d3a08d64198d26d4f2323f235790c04aeaab # read-only
tree of comit 5b53...

Given the purity of Linus' concept and his natural orientation towards
file systems rather than SCMs, this seems like a rather natural thing
to do.  If anyone is planning to do this and wants a helper, count me
in!

jon.
-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
-
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