* Re: Automatic merge failed, fix up by hand
From: Linus Torvalds @ 2005-08-24 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Len Brown, Git Mailing List
In-Reply-To: <7v3bp0m9ax.fsf@assigned-by-dhcp.cox.net>
On Tue, 23 Aug 2005, Junio C Hamano wrote:
>
> Only lightly tested, in the sense that I did only this one case
> and nothing else. For a large repository and with complex
> merges, "merge-base -a" _might_ end up reporting many
> candidates, in which case the pre-merge step to figure out the
> best merge base may turn out to be disastrously slow. I dunno.
Ok, I think your approach is the correct one. Just list all the commits,
and let the merge logic figure out which one is the best one.
Here, in case anybody cares, is an alternate approach, which sucks. It
_happens_ to pick the right parent in this case, but when I look at why it
picks it, it's pretty much just pure luck again. The distance function is
not good.
Just returning several entries is the correct thing to do, because then
you can make the distance function be based on the tree diffs, like you
do. That's _much_ better than trying to make the distance be based on some
topology.
So I append this patch just as a historical curiosity. Junio's patch is
clearly superior.
Linus
---
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
@@ -82,10 +82,84 @@ static struct commit *interesting(struct
* commit B.
*/
+/*
+ * Count the distance from one commit to the base, using a very
+ * stupid recursive algorithm. We only avoid recursion when seeing
+ * a single parent.
+ */
+static unsigned long count_distance(struct commit *head, struct commit *base)
+{
+ struct commit_list *parents;
+ unsigned long distance = ULONG_MAX;
+ unsigned long chain = 1;
+
+ /* Walk the chain of direct parents */
+ for (;;) {
+ parents = head->parents;
+ if (!parents)
+ goto no_parent;
+ /* Multiple parents? */
+ if (parents->next)
+ break;
+ head = parents->item;
+ if (head == base)
+ return chain;
+ chain++;
+ }
+
+ while (parents) {
+ struct commit *c = parents->item;
+ unsigned long d;
+
+ parents = parents->next;
+ if (c == base)
+ return chain;
+ if (c->object.flags & UNINTERESTING)
+ continue;
+ d = count_distance(c, base);
+ if (d < distance)
+ distance = d;
+ }
+ if (distance != ULONG_MAX)
+ return distance + chain;
+no_parent:
+ return ULONG_MAX;
+}
+
+/*
+ * There are some really nasty cases where we get multiple apparently
+ * equally valid parents, and we need to disambiguate them.
+ *
+ * We aim for the one whose total distance to the two revisions is the
+ * smallest, where distance is "x**2 + y**2" (we _much_ prefer a nice
+ * balanced equidistant one over one that is near to one but far from
+ * the other)
+ */
+static struct commit *pick_best_commit(struct commit_list *list, struct commit *rev1, struct commit *rev2)
+{
+ unsigned long distance = ULONG_MAX;
+ struct commit *best = NULL;
+
+ do {
+ struct commit *base = list->item;
+ unsigned long d1 = count_distance(rev1, base);
+ unsigned long d2 = count_distance(rev2, base);
+ unsigned long d = d1*d1 + d2*d2;
+
+fprintf(stderr, "distance analysis: %s: %lu %lu %lu\n", sha1_to_hex(base->object.sha1), d1, d2, d);
+ if (d < distance) {
+ distance = d;
+ best = base;
+ }
+ } while ((list = list->next) != NULL);
+ return best;
+}
+
static struct commit *common_ancestor(struct commit *rev1, struct commit *rev2)
{
struct commit_list *list = NULL;
struct commit_list *result = NULL;
+ struct commit_list *final = NULL;
if (rev1 == rev2)
return rev1;
@@ -122,7 +196,32 @@ static struct commit *common_ancestor(st
insert_by_date(p, &list);
}
}
- return interesting(result);
+
+ /*
+ * Go through the result list, and pick out unique
+ * members to put on the final list.
+ */
+ while (result) {
+ struct commit_list *entry = result;
+ struct commit *c = result->item;
+ result = result->next;
+ if (c->object.flags & UNINTERESTING)
+ continue;
+ if (c == rev1 || c == rev2)
+ return c;
+ entry->next = final;
+ final = entry;
+ c->object.flags |= UNINTERESTING;
+ }
+
+ if (!final)
+ return NULL;
+
+ /* Just one entry? */
+ if (!final->next)
+ return final->item;
+
+ return pick_best_commit(final, rev1, rev2);
}
int main(int argc, char **argv)
^ permalink raw reply
* Re: Automatic merge failed, fix up by hand
From: Junio C Hamano @ 2005-08-24 1:07 UTC (permalink / raw)
To: Len Brown; +Cc: Linus Torvalds, git
In-Reply-To: <7vek8kmb2a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Probably the ideal way would be to give merge-base an option to
> spit out all the candidates, and have the script try to see
> which ones yield the least number of non-trivial merges.
I first checked out your 702c7e.. commit, and slurped Linus tip
(back then, 81065e2f415af6c028eac13f481fb9e60a0b487b). Then I
ran git resolve with the attached patch (against the tip of
git.git "master" branch). Here is what happened, which seems to
work a little bit better, at least to me.
prompt$ git checkout -f
prompt$ git status
nothing to commit
prompt$ ls -l .git/HEAD
lrwxrwxrwx 1 junio src 26 Aug 23 15:43 .git/HEAD -> refs/heads/lenb
prompt$ git resolve HEAD origin 'Merge Linus into Lenb'
Trying to find the optimum merge base
Trying to merge 81065e2f415af6c028eac13f481fb9e60a0b487b into 702c7e7626deeabb057b6f529167b65ec2eefbdb using 3edea4833a1efcd43e1dff082bc8001fdfe74b34
Simple merge failed, trying Automatic merge
Auto-merging Documentation/acpi-hotkey.txt.
merge: warning: conflicts during merge
ERROR: Merge conflict in Documentation/acpi-hotkey.txt.
Auto-merging drivers/acpi/osl.c.
fatal: merge program failed
Automatic merge failed, fix up by hand
Only lightly tested, in the sense that I did only this one case
and nothing else. For a large repository and with complex
merges, "merge-base -a" _might_ end up reporting many
candidates, in which case the pre-merge step to figure out the
best merge base may turn out to be disastrously slow. I dunno.
---
git diff HEAD
diff --git a/git-resolve-script b/git-resolve-script
--- a/git-resolve-script
+++ b/git-resolve-script
@@ -49,7 +49,42 @@ if [ "$common" == "$head" ]; then
dropheads
exit 0
fi
-echo "Trying to merge $merge into $head"
+
+# Find optimum merge base if there are more than one candidate.
+LF='
+'
+common=$(git-merge-base -a $head $merge)
+case "$common" in
+?*"$LF"?*)
+ echo "Trying to find the optimum merge base"
+ G=.tmp-index$$
+ best=
+ best_cnt=-1
+ for c in $common
+ do
+ rm -f $G
+ GIT_INDEX_FILE=$G git-read-tree -m $c $head $merge \
+ 2>/dev/null || continue
+ if GIT_INDEX_FILE=$G git-write-tree 2>/dev/null
+ then
+ # This one results in just a Simple merge;
+ # It cannot become better than this.
+ best=$c
+ break
+ fi
+ # Otherwise, count the paths that are unmerged.
+ cnt=`GIT_INDEX_FILE=$G git-ls-files --unmerged | wc -l`
+ if test $best_cnt -le 0 -o $cnt -le $best_cnt
+ then
+ best=$c
+ best_cnt=$cnt
+ fi
+ done
+ rm -f $G
+ common="$best"
+esac
+
+echo "Trying to merge $merge into $head using $common"
git-read-tree -u -m $common $head $merge || exit 1
result_tree=$(git-write-tree 2> /dev/null)
if [ $? -ne 0 ]; then
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
@@ -82,13 +82,17 @@ static struct commit *interesting(struct
* commit B.
*/
-static struct commit *common_ancestor(struct commit *rev1, struct commit *rev2)
+static int show_all = 0;
+
+static int merge_base(struct commit *rev1, struct commit *rev2)
{
struct commit_list *list = NULL;
struct commit_list *result = NULL;
- if (rev1 == rev2)
- return rev1;
+ if (rev1 == rev2) {
+ printf("%s\n", sha1_to_hex(rev1->object.sha1));
+ return 0;
+ }
parse_commit(rev1);
parse_commit(rev2);
@@ -108,7 +112,7 @@ static struct commit *common_ancestor(st
if (flags == 3) {
insert_by_date(commit, &result);
- /* Mark children of a found merge uninteresting */
+ /* Mark parents of a found merge uninteresting */
flags |= UNINTERESTING;
}
parents = commit->parents;
@@ -122,26 +126,46 @@ static struct commit *common_ancestor(st
insert_by_date(p, &list);
}
}
- return interesting(result);
+
+ if (!result)
+ return 1;
+
+ while (result) {
+ struct commit *commit = result->item;
+ result = result->next;
+ if (commit->object.flags & UNINTERESTING)
+ continue;
+ printf("%s\n", sha1_to_hex(commit->object.sha1));
+ if (!show_all)
+ return 0;
+ commit->object.flags |= UNINTERESTING;
+ }
+ return 0;
}
+static const char merge_base_usage[] =
+"git-merge-base [--all] <commit-id> <commit-id>";
+
int main(int argc, char **argv)
{
- struct commit *rev1, *rev2, *ret;
+ struct commit *rev1, *rev2;
unsigned char rev1key[20], rev2key[20];
+ while (1 < argc && argv[1][0] == '-') {
+ char *arg = argv[1];
+ if (!strcmp(arg, "-a") || !strcmp(arg, "--all"))
+ show_all = 1;
+ else
+ usage(merge_base_usage);
+ argc--; argv++;
+ }
if (argc != 3 ||
get_sha1(argv[1], rev1key) ||
- get_sha1(argv[2], rev2key)) {
- usage("git-merge-base <commit-id> <commit-id>");
- }
+ get_sha1(argv[2], rev2key))
+ usage(merge_base_usage);
rev1 = lookup_commit_reference(rev1key);
rev2 = lookup_commit_reference(rev2key);
if (!rev1 || !rev2)
return 1;
- ret = common_ancestor(rev1, rev2);
- if (!ret)
- return 1;
- printf("%s\n", sha1_to_hex(ret->object.sha1));
- return 0;
+ return merge_base(rev1, rev2);
}
^ permalink raw reply
* Re: Automatic merge failed, fix up by hand
From: Linus Torvalds @ 2005-08-24 0:48 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <1124831571.13042.27.camel@firebird.lenb.worldpath.net>
On Tue, 23 Aug 2005, Len Brown wrote:
>
> I'm having trouble using git for merging kernel trees.
>
> git seems to manufacture conflicts in files that
> I never touched, and on some files it completely
> throws up its arms, see "Not handling case" below.
Cool.
You've found a case where git-merge-base finds what appears to be two
equally good merge candidates, but they really aren't.
The merge candidates are 30e332f3307e9f7718490a706e5ce99f0d3a7b26 and
3edea4833a1efcd43e1dff082bc8001fdfe74b34.
To see this graphically, do:
echo 30e332f3307e9f7718490a706e5ce99f0d3a7b26 > .git/refs/tags/selected-merge-base
echo 3edea4833a1efcd43e1dff082bc8001fdfe74b34 > .git/refs/tags/other-merge-base
echo 81065e2f415af6c028eac13f481fb9e60a0b487b > .git/refs/tags/linus-head
echo 702c7e7626deeabb057b6f529167b65ec2eefbdb > .git/refs/tags/lenb-head
gitk --all
and notice how the not-selected one is:
Author: Antonino A. Daplas <adaplas@gmail.com> 2005-08-15 06:29:11
Committer: Linus Torvalds <torvalds@g5.osdl.org> 2005-08-15 09:59:39
Tags: not-selected
while the selected on is:
Author: Luming Yu <luming.yu@intel.com> 2005-08-11 21:31:00
Committer: Len Brown <len.brown@intel.com> 2005-08-15 12:46:58
Tags: selected
and the reason we chose that one is that it's three hours later than the
other one, and we don't know any better.
> Not clear how I got into this state -- probably
> something to do with adding commits on branches
> and them git-pull-branch'ing them into the master;
> combined with updating the master from-linus.
No, it's git.
Well, it's git, together with your propensity to merge old work, which
causes this kind of confusion where there are two "equally good" points to
choose from as the merge base, and git chose the wrong one because it
_looked_ newer and there was a recent merge to an old version of my tree.
Cross-merges cause this, but I'm sure there's a good algorithm for
selecting _which_ of the two interesting commits to pick.
Give me a moment to think about this.
Linus
^ permalink raw reply
* Re: [PATCH] Introduce "reset type" flag to "git reset"
From: Yasushi SHOJI @ 2005-08-24 0:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Ravnborg, git, Linus Torvalds
In-Reply-To: <7vpss4mbe0.fsf@assigned-by-dhcp.cox.net>
At Tue, 23 Aug 2005 17:22:47 -0700,
Junio C Hamano wrote:
>
> Yasushi SHOJI <yashi@atmark-techno.com> writes:
>
> > for --hard option, what you want to do is to completely revert the
> > current state of your index file and work tree to known point.
> >
> > for that, how about git-revert-script?
>
> "git revert" is to create a commit that reverts a previous
> commit, which I think is quite different from what we have been
> discussing so far.
ah, ok. I was gonna suggest git-revert-script for the name but quick
check showed me that we already have that script. so I just thought it
does the thing.
--
yashi
^ permalink raw reply
* Re: Automatic merge failed, fix up by hand
From: Junio C Hamano @ 2005-08-24 0:29 UTC (permalink / raw)
To: Len Brown; +Cc: Linus Torvalds, git
In-Reply-To: <7vzmr8mci2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I think merge-base, even though we attempted to fix it recently,
> is still confused and that is one of the reasons why you are
> getting this.
>
> prompt$ git-rev-parse origin test-lenb-merge
> 81065e2f415af6c028eac13f481fb9e60a0b487b
> 702c7e7626deeabb057b6f529167b65ec2eefbdb
-->8-- snip -->8--
> + Merge ../to-linus-stable/
> ++ [ACPI] re-enable platform-specific hotkey drivers by default
> + ARM: 2851/1: Fix NWFPE extended precision exception handling
> ++ [origin~34] intelfb/fbdev: Save info->flags in a local variable
> prompt$ git-rev-parse origin~34
> 3edea4833a1efcd43e1dff082bc8001fdfe74b34
I spoke too fast. merge-base is not giving you an incorrect
answer. It just happens that the answer was way suboptimal.
The "[ACPI] re-enable platform-specific hotkey" is what it
chose, and my monkey guessing origin~34 happened to be better
merge base, but the logic used by merge-base is to pick the
latest (from wallclock wise) commit among several candidates,
and by that criteria it did the "right" thing.
In this case, the "right" thing was a wrong decision. So we
probably should revisit how we choose the "best" merge base
among candidates. I think "origin~34" which happened to be the
last one output by "git show-branch" was just an accident, not a
good rule to follow, so changing merge-base to use the one that
the other command shows the last would not be a good way to fix
this.
Probably the ideal way would be to give merge-base an option to
spit out all the candidates, and have the script try to see
which ones yield the least number of non-trivial merges.
Linus?
^ permalink raw reply
* Re: Automatic merge failed, fix up by hand
From: Len Brown @ 2005-08-24 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vzmr8mci2.fsf@assigned-by-dhcp.cox.net>
On Tue, 2005-08-23 at 19:58 -0400, Junio C Hamano wrote:
> Len Brown <len.brown@intel.com> writes:
>
> >> I could get to 81065e2f415af6... commit (Linus tip at this
> >> moment), so if you can tell me where to snarf the other commit
> >> (702c7e76....) that would help me diagnose the problem a lot.
> >
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/lenb/to-akpm.git
>
> Thanks.
>
> I think merge-base, even though we attempted to fix it recently,
> is still confused and that is one of the reasons why you are
> getting this.
>
> prompt$ git-rev-parse origin test-lenb-merge
> 81065e2f415af6c028eac13f481fb9e60a0b487b
> 702c7e7626deeabb057b6f529167b65ec2eefbdb
> prompt$ git-merge-base origin test-lenb-merge
> 30e332f3307e9f7718490a706e5ce99f0d3a7b26
> prompt$ git show-branch origin test-lenb-merge
> ! [origin] zd1201 kmalloc size fix
> * [test-lenb-merge] [ACPI] fix ia64 build issues resulting from
> L...
> --
> + [origin] zd1201 kmalloc size fix
> + [origin~1] md: make sure resync gets started when array starts.
> + [origin~2] preempt race in getppid
> + [origin~3] Merge master.kernel.org:/pub/scm/linux/kernel/git/da
> -- >8 -- snip -- >8 --
> + Merge ../to-linus-stable/
> ++ [ACPI] re-enable platform-specific hotkey drivers by default
> + ARM: 2851/1: Fix NWFPE extended precision exception handling
> ++ [origin~34] intelfb/fbdev: Save info->flags in a local variable
> prompt$ git-rev-parse origin~34
> 3edea4833a1efcd43e1dff082bc8001fdfe74b34
>
> Notice that show-branch, which walks the commit ancestry chain
> pretty much the same way merge-base does, notices and stops at
> origin~34 (that's 34th generation first parent commit from Linus
> tip) that is the common commit between the two heads being
> merged? And that commit, 3edea48... is different from what
> merge-base is reporting.
>
> If I maually run merge-cache using origin~34 as the merge base,
> only the following two files needs to result in non-simple merge:
>
> Documentation/acpi-hotkey.txt
> drivers/acpi/osl.c
>
> Do these two files match your expectation?
No, I don't think so.
Unless I missed something, to-akpm should be a proper super-set
of from-linus, so I wouldn't expect a merge on these two.
> I'll take a look at merge-base.c next, but just in case I CC:ed
> this to Linus, who is more familiar with that code.
thanks,
-Len
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Junio C Hamano @ 2005-08-24 0:23 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxvf1wd24m.fsf@arm.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> What's the definition of a parent in GIT terms? What are the
> restriction for a commit object to be a parent? Can a parent be an
> arbitrarily chosen commit?
Yes it can. GIT does not care if the commit ancestry does not
make sense in contents terms (i.e. you can record one tree
object in a commit object, and record another, completely
unrelated tree object in a commit object that has the first
commit object as its parent). The "git-diff-tree" output from
comparing those two commits may not make _any_ sense at all to
the human, though, but that is not a problem for GIT to do its
work.
> That's what I've been thinking. StGIT currently only implements the
> external view.
>
> An StGIT patch is a represented by a top and bottom commit
> objects. The bottom one is the same as the parent of the top
> commit. The patch is the diff between the top's tree id and the
> bottom's tree id.
>
> Jan's proposal is to allow a freeze command to save the current top
> hash and later be used as a second parent for the newly generated
> top. The problem I see with this approach is that (even for the
> internal view you described) the newly generated top will have two
> parents, new-bottom and old-top, but only the diff between new-top and
> new-bottom is meaningful. The diff between new-top and old-top (as a
> parent-child relation) wouldn't contain anything relevant to the patch
> but all the new changes to the base of the stack.
>
> Is the above an acceptable usage of the GIT DAG structure?
Surely, as long as it stays internal as StGIT patch stacks.
Even when it is exported (i.e. you manage to have other non
StGIT managed tree to pull and merge with such a commit), the
development history _might_ look funny and complicated, but it
should not be a problem for GIT to handle. After all, you are
doing complicated thing in the StGIT patch stacks when you pop,
push and freeze number of times, so your history is complicated.
If you want to record that history at least for StGIT internal
bookkeeping purposes, GIT should not prevent you from doing it.
Having said that, I would 100% agree with you that having a
cleansed external view would be a good idea. It makes merging
with StGIT managed repositories much more acceptable to ordinary
GIT managed history.
^ permalink raw reply
* Re: [PATCH] Introduce "reset type" flag to "git reset"
From: Junio C Hamano @ 2005-08-24 0:22 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: Sam Ravnborg, git, Linus Torvalds
In-Reply-To: <87y86s2nvi.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> writes:
> for --hard option, what you want to do is to completely revert the
> current state of your index file and work tree to known point.
>
> for that, how about git-revert-script?
"git revert" is to create a commit that reverts a previous
commit, which I think is quite different from what we have been
discussing so far.
^ permalink raw reply
* Fix silly pathspec bug in git-ls-files
From: Linus Torvalds @ 2005-08-24 0:14 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
The "verify_pathspec()" function doesn't test for ending NUL character in
the pathspec, causing some really funky and unexpected behaviour. It just
happened to work in the cases I had tested.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -496,7 +496,7 @@ static void verify_pathspec(void)
char c = n[i];
if (prev && prev[i] != c)
break;
- if (c == '*' || c == '?')
+ if (!c || c == '*' || c == '?')
break;
if (c == '/')
len = i+1;
^ permalink raw reply
* Re: [PATCH] Introduce "reset type" flag to "git reset"
From: Yasushi SHOJI @ 2005-08-24 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Ravnborg, git, Linus Torvalds
In-Reply-To: <7vacj8nw5v.fsf@assigned-by-dhcp.cox.net>
At Tue, 23 Aug 2005 15:08:44 -0700,
Junio C Hamano wrote:
>
> Sam Ravnborg <sam@ravnborg.org> writes:
>
> > But --soft, --hard looks rather confusing to me.
> >
> > Something like --force or --prune may be a bit more intuitive, and let
> > default behaviour be the one you name --soft for now.
>
> I do not have objections to removing --mixed, but I do not find
> --force/--prune any less confusing than --soft/--hard. Its just
> a terminology so once people get used to it anything would do.
> But I agree that we need to come up with a good name for them.
> I do not think --force/--prune is it, though.
I think the point is "what is the target?".
I believe "git reset" is targeting at the index file and only the
index file and nothing more. it's that simple.
what we want instead is a command to sync/reset/revert both index and
tree to know working point. so this isn't core plumbing but as a user
of git, i'm sure it's very handy to have it.
--soft one is simple to think, so i'm starting with this one. let's
assume that, as you described in the original post, this one is
intended to be used to rework on the work _you_ have before. that
means that _you_ know exactly what you are doing.
there might be a case, and this happned to me quite some time when I
was working with quilt, which you don't want to automatically add all
the files you added on the privious commit. ie. moving defines from
header to .c, splitting a work to two commits.
so in this case, it's ideal to just use "git reset" if the command
lists files removed from the index.
for --hard option, what you want to do is to completely revert the
current state of your index file and work tree to known point.
for that, how about git-revert-script? can we add --force option to
that command so that even if your working tree is dirty it reverts to
the specified point?
--
yashi
^ permalink raw reply
* Re: [RFC] Removing deleted files after checkout
From: Junio C Hamano @ 2005-08-24 0:02 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Carl Baldwin, git
In-Reply-To: <Pine.LNX.4.63.0508231830280.23242@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I think that git-read-tree -u ought to remove a directory if it removes
> the last file (or directory) in it.
I concur and do not have much objections to a patch that would
do so.
^ permalink raw reply
* Re: Automatic merge failed, fix up by hand
From: Junio C Hamano @ 2005-08-23 23:58 UTC (permalink / raw)
To: Len Brown; +Cc: Linus Torvalds, git
In-Reply-To: <1124836282.14730.4.camel@toshiba>
Len Brown <len.brown@intel.com> writes:
>> I could get to 81065e2f415af6... commit (Linus tip at this
>> moment), so if you can tell me where to snarf the other commit
>> (702c7e76....) that would help me diagnose the problem a lot.
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/lenb/to-akpm.git
Thanks.
I think merge-base, even though we attempted to fix it recently,
is still confused and that is one of the reasons why you are
getting this.
prompt$ git-rev-parse origin test-lenb-merge
81065e2f415af6c028eac13f481fb9e60a0b487b
702c7e7626deeabb057b6f529167b65ec2eefbdb
prompt$ git-merge-base origin test-lenb-merge
30e332f3307e9f7718490a706e5ce99f0d3a7b26
prompt$ git show-branch origin test-lenb-merge
! [origin] zd1201 kmalloc size fix
* [test-lenb-merge] [ACPI] fix ia64 build issues resulting from L...
--
+ [origin] zd1201 kmalloc size fix
+ [origin~1] md: make sure resync gets started when array starts.
+ [origin~2] preempt race in getppid
+ [origin~3] Merge master.kernel.org:/pub/scm/linux/kernel/git/da
-- >8 -- snip -- >8 --
+ Merge ../to-linus-stable/
++ [ACPI] re-enable platform-specific hotkey drivers by default
+ ARM: 2851/1: Fix NWFPE extended precision exception handling
++ [origin~34] intelfb/fbdev: Save info->flags in a local variable
prompt$ git-rev-parse origin~34
3edea4833a1efcd43e1dff082bc8001fdfe74b34
Notice that show-branch, which walks the commit ancestry chain
pretty much the same way merge-base does, notices and stops at
origin~34 (that's 34th generation first parent commit from Linus
tip) that is the common commit between the two heads being
merged? And that commit, 3edea48... is different from what
merge-base is reporting.
If I maually run merge-cache using origin~34 as the merge base,
only the following two files needs to result in non-simple merge:
Documentation/acpi-hotkey.txt
drivers/acpi/osl.c
Do these two files match your expectation?
I'll take a look at merge-base.c next, but just in case I CC:ed
this to Linus, who is more familiar with that code.
^ permalink raw reply
* baffled again
From: tony.luck @ 2005-08-23 22:56 UTC (permalink / raw)
To: git
So I have another anomaly in my GIT tree. A patch to
back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
in my release branch at commit
62d75f3753647656323b0365faa43fc1a8f7be97
appears to have been lost when I merged the release branch to
the test branch at commit
0c3e091838f02c537ccab3b6e8180091080f7df2
So now this file still has this:
/* SSC_WAIT_COMPLETION appears to want this large alignment. gcc < 4
* seems to give it by default, however gcc > 4 is smarter and may
* not.
*/
struct disk_stat {
int fd;
unsigned count;
} __attribute__ ((aligned (16)));
in the test branch, when I think the comment and __attribute__
should have been backout out.
-Tony
Tree is at rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
^ permalink raw reply
* Re: [RFC] Removing deleted files after checkout
From: Daniel Barkalow @ 2005-08-23 22:34 UTC (permalink / raw)
To: Carl Baldwin; +Cc: Junio C Hamano, git
In-Reply-To: <20050823222151.GA15321@hpsvcnb.fc.hp.com>
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> The thing that this doesn't do is remove empty directories when the last
> file is deleted. I once expressed the opinion in a previous thread that
> directories should be added and removed explicitly in git. (Thus
> allowing an empty directory to be added). If this were to happen then
> this case would get handled correctly. However, if git stays with the
> status quo then I think that git-read-tree -u should be changed to
> remove the empty directory. This would make it consistent.
I think that git-read-tree -u ought to remove a directory if it removes
the last file (or directory) in it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Automatic merge failed, fix up by hand
From: Len Brown @ 2005-08-23 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhddgnw9q.fsf@assigned-by-dhcp.cox.net>
On Tue, 2005-08-23 at 18:06 -0400, Junio C Hamano wrote:
> Len Brown <len.brown@intel.com> writes:
>
> > The merge issue below is reproduced in a "git clone -l" copy
> > with no plain files present.
>
> Meaning you did not have any file in the working tree? It seems
> to me that what is happenning is the resolve is trying to merge
> the head of your tree and from-linus, but at the same time it
> notices that you removed those files from your working tree and
> thinks that is what you would want to do.
Doesn't matter if the merge is after a git checkout -f
or not. I was just pointing out that it also fails
if there are no plain files checked out.
> I could get to 81065e2f415af6... commit (Linus tip at this
> moment), so if you can tell me where to snarf the other commit
> (702c7e76....) that would help me diagnose the problem a lot.
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/lenb/to-akpm.git
fails when merged into latest linus, or when latest linus
is merged into it.
I suspect some artifact of my patches being based on
one of several branches rooted at 2.6.12 is the issue,
and that in switching between latest 2.6.13 and stable
2.6.12 branches, some state has bled through that
now confuses the heck out of resolve.
thanks,
-Len
^ permalink raw reply
* Re: [RFC] Removing deleted files after checkout
From: Carl Baldwin @ 2005-08-23 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Baldwin, git, Daniel Barkalow
In-Reply-To: <7vvf1wnwtl.fsf@assigned-by-dhcp.cox.net>
Ok, the following is what I came up with based on your response. This
is .git/hooks/update. It mostly works in my situation. See below for
my discussion on what didn't work.
#!/bin/sh
export PATH=/usr/local/bin:/usr/bin:/bin
# cd to the root of the project directory (assume one dir up from GIT_DIR)
cd $GIT_DIR/..
unset GIT_DIR
if expr "$2" : '0*$' >/dev/null; then
git-read-tree --reset $3 &&
git-checkout-cache -q -f -u -a
else
git-read-tree -m -u $2 $3
fi
exit 0
# --- snip ---
The thing that this doesn't do is remove empty directories when the last
file is deleted. I once expressed the opinion in a previous thread that
directories should be added and removed explicitly in git. (Thus
allowing an empty directory to be added). If this were to happen then
this case would get handled correctly. However, if git stays with the
status quo then I think that git-read-tree -u should be changed to
remove the empty directory. This would make it consistent.
What do you think? Ideas?
Carl
On Tue, Aug 23, 2005 at 02:54:30PM -0700, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> >> > If you don't use -f, git-checkout-script removes deleted files. Using -f
> >> > tells it to ignore the old index, which means that it can't tell the
> >> > difference between removed files and files that weren't tracked at all.
>
> Yes and no. "git checkout" assumes that the index file and the
> working tree somewhat resembles what is in .git/HEAD commit.
> Since push operation updates .git/HEAD commit without touching
> the index file, that assumption does not hold.
>
> The update hook gets old commit name and new commit name, so you
> should be able to do (untested):
>
> git-read-tree -m -u $old_commit $new_commit
>
> there, of course after making sure that you had old_commit (the
> first time push happens to a new ref you would not have that one).
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Daniel Barkalow @ 2005-08-23 22:23 UTC (permalink / raw)
To: Jan Veldeman; +Cc: Catalin Marinas, git
In-Reply-To: <20050823212305.GA5936@fanta>
On Tue, 23 Aug 2005, Jan Veldeman wrote:
> Daniel Barkalow wrote:
>
> > On Tue, 23 Aug 2005, Catalin Marinas wrote:
> >
> > Something is legitimate as a parent if someone took that commit and did
> > something to it to get the new commit. The operation which caused the
> > change is not specified. But you only want to include it if anyone cares
> > about the parent.
>
> This is indeed what I thought a parent should be used for. As an adition,
> I'll try to explain why I would sometimes want to care about some parents:
>
> I want to track a mailine tree, but have quite a few changes, which shoudn't
> be commited to the mainline immediately (let's call it my development tree).
> This is why I would use stgit. But I would also want to colaborate with
> other developers on this development tree, so I sometimes want to make
> updates available of this development tree to the others. This is where
> current stgit falls short. To easily share this development tree, I want
> some history (not all, only the ones I choose) of this development tree
> included, so that the other developers can easily follow my development.
>
> The parents which should be visible to the outside, will always be versions
> of my development tree, which I have previously pushed out. My way of
> working would become:
> * make changes, all over the place, using stgit
> * still make changes (none of these gets tracked, intermittent versions are
> lost)
> * having a good day: changes looks good, I want to push this out:
> * push my tree out
> * stgit-free (which makes the pushed out commits, the new parents of my
> stgit patches)
> * restart from top
I'm not sure how applicable to this situation stgit really is; I see stgit
as optimized for the case of a patch set which is basically done, where
you want to keep it applicable to the mainline as the mainline advances.
For your application, I'd just have a git branch full of various stuff,
and then generate clean commits by branching mainline, diffing development
against it, cutting the diff down to just what I want to push, and
applying that. Then the clean patch goes into stgit.
> [...]
> > This also depends on how exactly freeze is used; if you use it before
> > commiting a modification to the patch without rebasing, you get:
> >
> > old-top -> new-top
> > ^ ^
> > \ /
> > bottom
> >
> > bottom to old-top is the old patch
> > bottom to new-top is the new patch
> > old-top to new-top is the change to the patch
> >
> > Then you want to keep new-top as a parent for rebasings until one of these
> > is frozen. These links are not interesting to look at, but preserve the
> > path to the old-top:new-top change, which is interesting.
>
> my proposal does something like this, but a little more: not only does it
> keep track of the link between old-top and new-top, it also keeps track of
> the links between old-patch-in-between and new-patch-in-between.
> (This makes sense when the top is being removed or reordered)
I was thinking of this as being the top and bottom commits for a single
tracked patch, not as a whole series. I think patches lower wouldn't be
affected, and patches higher would see this as a rebase.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Introduce "reset type" flag to "git reset"
From: Junio C Hamano @ 2005-08-23 22:08 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git, Linus Torvalds
In-Reply-To: <20050823202637.GA8061@mars.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> writes:
> But --soft, --hard looks rather confusing to me.
>
> Something like --force or --prune may be a bit more intuitive, and let
> default behaviour be the one you name --soft for now.
I do not have objections to removing --mixed, but I do not find
--force/--prune any less confusing than --soft/--hard. Its just
a terminology so once people get used to it anything would do.
But I agree that we need to come up with a good name for them.
I do not think --force/--prune is it, though.
> I think it would make sense to be able to specify the topmost SHA1 (or
> HEAD:5 or HEAD^^^^^) from where the reset should start.
"git reset --hard HEAD~5" should work. Sorry, the colon ":"
turns out to be confusing to refspec notation <src>:<dst> used
in fetch/push and was replaced with a tilde "~" some time ago.
^ permalink raw reply
* Re: [RFC] Removing deleted files after checkout
From: Daniel Barkalow @ 2005-08-23 22:12 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050823214020.GA3763@hpsvcnb.fc.hp.com>
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> The point is to push and use a post-update hook to do the checkout. So,
> this won't be possible.
You could have the remote repository be something like
"~/git/website.git", and have a hook which does: "cd ~/www; git pull
~/git/website.git/". That is, have three things: the directory where you
work on stuff, the central storage location, and the area that the web
server serves, and have the storage location automatically update the web
server area. That's what I do with my website section that's still in CVS,
and the general concept is good (and means that the "real" repository
isn't somewhere the web server is poking around).
> > which will correctly identify before and after, and remove any files that
> > were removed.
> >
> > Alternatively, you could do, at point 1:
> >
> > cp .git/refs/master .git/refs/deployed
> > git checkout deployed
>
> How to get a post-update hook to do this? I suppose an update script
> could set this up for the post-update to later use.
If you have "deployed" checked out, and you push to "master" in the same
repository, having the hook do "git resolve deployed master auto-update"
should work.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Automatic merge failed, fix up by hand
From: Junio C Hamano @ 2005-08-23 22:06 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <1124831571.13042.27.camel@firebird.lenb.worldpath.net>
Len Brown <len.brown@intel.com> writes:
> The merge issue below is reproduced in a "git clone -l" copy
> with no plain files present.
Meaning you did not have any file in the working tree? It seems
to me that what is happenning is the resolve is trying to merge
the head of your tree and from-linus, but at the same time it
notices that you removed those files from your working tree and
thinks that is what you would want to do.
I could get to 81065e2f415af6... commit (Linus tip at this
moment), so if you can tell me where to snarf the other commit
(702c7e76....) that would help me diagnose the problem a lot.
Thanks.
^ permalink raw reply
* Re: [RFC] Removing deleted files after checkout
From: Junio C Hamano @ 2005-08-23 21:54 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.63.0508231713450.23242@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> > If you don't use -f, git-checkout-script removes deleted files. Using -f
>> > tells it to ignore the old index, which means that it can't tell the
>> > difference between removed files and files that weren't tracked at all.
Yes and no. "git checkout" assumes that the index file and the
working tree somewhat resembles what is in .git/HEAD commit.
Since push operation updates .git/HEAD commit without touching
the index file, that assumption does not hold.
The update hook gets old commit name and new commit name, so you
should be able to do (untested):
git-read-tree -m -u $old_commit $new_commit
there, of course after making sure that you had old_commit (the
first time push happens to a new ref you would not have that one).
^ permalink raw reply
* Re: [RFC] Removing deleted files after checkout
From: Carl Baldwin @ 2005-08-23 21:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Carl Baldwin, git
In-Reply-To: <Pine.LNX.4.63.0508231713450.23242@iabervon.org>
On Tue, Aug 23, 2005 at 05:27:12PM -0400, Daniel Barkalow wrote:
> On Tue, 23 Aug 2005, Carl Baldwin wrote:
>
> > On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote:
> > > On Tue, 23 Aug 2005, Carl Baldwin wrote:
> > >
> > > > Hello,
> > > >
> > > > I recently started using git to revision control the source for my
> > > > web-page. I wrote a post-update hook to checkout the files when I push
> > > > to the 'live' repository.
> > > >
> > > > In this particular context I decided that it was important to me to remove
> > > > deleted files after checking out the new HEAD. I accomplished this by running
> > > > git-ls-files before and after the checkout.
> > > >
> > > > Is there a better way? Could there be some way built into git to easily
> > > > find out what files dissappear when replacing the current index with one
> > > > from a new tree? Is there already? The behavior of git should NOT
> > > > change to delete these files but I would argue that some way should
> > > > exist to query what files disappeared if removing them is desired.
> > >
> > > If you don't use -f, git-checkout-script removes deleted files. Using -f
> > > tells it to ignore the old index, which means that it can't tell the
> > > difference between removed files and files that weren't tracked at all.
> >
> > Maybe I'm doing something wrong. This does not happen for me.
> >
> > I tried a simple test with git v0.99.4...
> >
> > cd
> > mkdir test-git && cd test-git/
> > echo testing | cg-init
> > echo contents > file
> > git-add-script file
> > git-commit-script -m 'testing'
>
> [point 1]
>
> > cd ..
> > cg-clone test-git/.git/ test-git2
> > cd test-git2
> > cg-rm file
> > git-commit-script -m 'testing'
> > ls
>
> > cg-push
> > cd ../test-git
> > git-checkout-script
>
> Ah, okay. I think "push" and "checkout" don't play that well together;
> "push" changes the ref, which "checkout" uses to determine what it expects
> for the old contents, and then it's confused.
>
> What you probably actually want is:
>
> cd ../test-git
> git pull ../test-git2
The point is to push and use a post-update hook to do the checkout. So,
this won't be possible.
> which will correctly identify before and after, and remove any files that
> were removed.
>
> Alternatively, you could do, at point 1:
>
> cp .git/refs/master .git/refs/deployed
> git checkout deployed
How to get a post-update hook to do this? I suppose an update script
could set this up for the post-update to later use.
Thanks,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Pavel Roskin @ 2005-08-23 21:33 UTC (permalink / raw)
To: Petr Baudis, git
Hello!
This patch changes cg-pull so that if the branch is not specified, it
takes origin's .git/HEAD without first trying .git/refs/heads/master.
This removes preferential treatment of the "master" branch, allowing the
upstream to use another name for the default branch. To get the master
branch, users would have to append "#master" to the URL.
Local URL handling needs to be fixed to handle .git/HEAD properly, since
it's a symlink in the upstream directory. A new flag "-b" for fetch_*
functions is introduced, meaning "dereference" (like in GNU cp).
To do: the code needs refactoring with better option handling.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -67,6 +67,8 @@ pull_progress()
fetch_rsync()
{
+ [ "$1" = "-b" ] && shift
+
redir=
if [ "$1" = "-i" ]; then # ignore-errors
redir="2>/dev/null"
@@ -108,6 +110,7 @@ pull_rsync()
fetch_http()
{
+ [ "$1" = "-b" ] && shift
[ "$1" = "-i" ] && shift
[ "$1" = "-s" ] && shift
@@ -158,6 +161,7 @@ pull_http()
fetch_ssh()
{
+ [ "$1" = "-b" ] && shift
[ "$1" = "-i" ] && shift
[ "$1" = "-s" ] && shift
@@ -205,6 +209,11 @@ fetch_local()
[ "$1" = "-s" ] && shift
cp_flags_l="-vdpR"
+ if [ "$1" = "-b" ]; then
+ cp_flags_l="-vb" # Dereference symlinks
+ shift
+ fi
+
if [ "$1" = "-u" ]; then
cp_flags_l="$cp_flags_l -fu$can_hardlink"
suggest_hardlink=
@@ -255,7 +264,7 @@ name=${ARGS[0]}
[ "$name" ] || die "where to pull from?"
uri=$(cat "$_git/branches/$name" 2>/dev/null) || die "unknown branch: $name"
-rembranch=master
+rembranch=
if echo "$uri" | grep -q '#'; then
rembranch=$(echo $uri | cut -d '#' -f 2)
uri=$(echo $uri | cut -d '#' -f 1)
@@ -308,13 +317,13 @@ orig_head=
mkdir -p $_git/refs/heads
-rsyncerr=
-$fetch -i "$uri/refs/heads/$rembranch" "$_git/refs/heads/.$name-pulling" || rsyncerr=1
-if [ "$rsyncerr" ] && [ "$rembranch" = "master" ]; then
- rsyncerr=
- $fetch -s "$uri/HEAD" "$_git/refs/heads/.$name-pulling" || rsyncerr=1
+if [ "$rembranch" ]; then
+ $fetch -i "$uri/refs/heads/$rembranch" "$_git/refs/heads/.$name-pulling" ||
+ die "unable to get the head pointer of branch $rembranch"
+else
+ $fetch -b -s "$uri/HEAD" "$_git/refs/heads/.$name-pulling" ||
+ die "unable to get the HEAD branch"
fi
-[ "$rsyncerr" ] && die "unable to get the head pointer of branch $rembranch"
new_head=$(cat "$_git/refs/heads/.$name-pulling")
if ! [ "$symlinked" ]; then
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC] Removing deleted files after checkout
From: Daniel Barkalow @ 2005-08-23 21:27 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050823205052.GA13311@hpsvcnb.fc.hp.com>
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote:
> > On Tue, 23 Aug 2005, Carl Baldwin wrote:
> >
> > > Hello,
> > >
> > > I recently started using git to revision control the source for my
> > > web-page. I wrote a post-update hook to checkout the files when I push
> > > to the 'live' repository.
> > >
> > > In this particular context I decided that it was important to me to remove
> > > deleted files after checking out the new HEAD. I accomplished this by running
> > > git-ls-files before and after the checkout.
> > >
> > > Is there a better way? Could there be some way built into git to easily
> > > find out what files dissappear when replacing the current index with one
> > > from a new tree? Is there already? The behavior of git should NOT
> > > change to delete these files but I would argue that some way should
> > > exist to query what files disappeared if removing them is desired.
> >
> > If you don't use -f, git-checkout-script removes deleted files. Using -f
> > tells it to ignore the old index, which means that it can't tell the
> > difference between removed files and files that weren't tracked at all.
>
> Maybe I'm doing something wrong. This does not happen for me.
>
> I tried a simple test with git v0.99.4...
>
> cd
> mkdir test-git && cd test-git/
> echo testing | cg-init
> echo contents > file
> git-add-script file
> git-commit-script -m 'testing'
[point 1]
> cd ..
> cg-clone test-git/.git/ test-git2
> cd test-git2
> cg-rm file
> git-commit-script -m 'testing'
> ls
> cg-push
> cd ../test-git
> git-checkout-script
Ah, okay. I think "push" and "checkout" don't play that well together;
"push" changes the ref, which "checkout" uses to determine what it expects
for the old contents, and then it's confused.
What you probably actually want is:
cd ../test-git
git pull ../test-git2
which will correctly identify before and after, and remove any files that
were removed.
Alternatively, you could do, at point 1:
cp .git/refs/master .git/refs/deployed
git checkout deployed
Then, after the push and cd:
git checkout master
cp .git/refs/master .git/refs/deployed
git checkout deployed
because checkout does remove files if you switch from a branch with them
(e.g., deployed) to one without them (master, after the push).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Spell __attribute__ correctly in cache.h.
From: Jason Riedy @ 2005-08-23 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64u1ya7c.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- > BTW, how would people feel about replacing the
- > setenv() and unsetenv() calls with the older putenv()?
- No comment on this one at this moment until I do my own digging
- a bit.
If you're interested, I have a few patches in
http://www.cs.berkeley.edu/~ejr/gits/git.git#portable
that let git compile with xlc on AIX and Sun's non-c99
cc on Solaris. Changes:
+ Replace C99 array initializers with code.
+ Replace unsetenv() and setenv() with older putenv().
+ Include sys/time.h in daemon.c.
+ Fix ?: statements.
+ Replace zero-length array decls with [].
The top two may or may not be acceptable. The third may
not be necessary if I can find the right -Ds for fd_set.
The last two just remove GNU C extensions. Makefile
changes (including extra -Ds for features) not included,
but could be. Tell me if you want any of these mailed.
Not all the tests pass on non-Linux, but I won't have time
to look at them for a bit. With the GNU findutils and
coreutils, it works well enough for basic use. The failing
tests might be from using non-GNU utilities. Rooting out
all the dependencies is a tad painful.
Jason
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox