* Re: t5505-remote fails on Windows
From: Jeff King @ 2009-03-19 20:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johannes Sixt, Jay Soffian, Git Mailing List
In-Reply-To: <7vhc1pai84.fsf@gitster.siamese.dyndns.org>
On Thu, Mar 19, 2009 at 04:02:19AM -0700, Junio C Hamano wrote:
> > Do we really want an API for that? Calling qsort() directly should be
> > obvious enough, no?
>
> I think so. If it were done like this (notice the lack of double
> indirection in the cmp_fn signature):
>
> typedef int string_list_item_cmp_fn(const struct string_list_item *, const struct string_list_item *);
>
> void sort_string_list_with_fn(struct string_list *list, string_list_item_cmp_fn *);
>
> it would have made more sense, though.
IIRC, that is actually not valid C according to the standard (that is,
even though a void* can be implicitly assigned to any other pointer, a
function taking a void* and a function taking another pointer do not
necessarily have the same function signature or calling conventions).
Which is why cmp_items in string-list.c already does the indirection.
That being said, I think this is probably one of those cases where it
works fine on any sane platform that we care about and we can choose to
ignore the standard.
Actually, I think an even nicer API would be to give a function that
_just_ compares the util fields; string_list_sort() would sort on the
"string" fields, and only call the util cmp to sort entries with equal
strings. Sadly, because qsort lacks a slot for extra data to pass to the
callback, implementing this ends up with a global variable:
static int (*cmp_util)(const void *, const void *);
int cmp_items(const void *a, const void *b)
{
const struct string_list_item *one = a;
const struct string_list_item *two = b;
int cmp = strcmp(one->string, two->string);
return cmp ? cmp : cmp_util(one->util, b->util);
}
int sort_string_list_with_util(struct string_list *list,
int (*fn)(const void *, const void *))
{
cmp_util = fn;
qsort(list->items, list->nr, sizeof(*list->items), cmp_items);
}
If only C had closures. ;)
But this is really getting beyond the issue at hand. I can submit a
finalized patch; just let me know how you prefer it.
-Peff
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Markus Heidelberg @ 2009-03-19 20:04 UTC (permalink / raw)
To: Eric Raible; +Cc: Santi Béjar, Eric Raible, git
In-Reply-To: <279b37b20903191252h4c1541a1m8e391e01114d2ce6@mail.gmail.com>
Eric Raible, 19.03.2009:
> 2009/3/19 Markus Heidelberg <markus.heidelberg@web.de>:
> >
> > If scrolling through a history with many branches (so many parallel
> > lines) like git.git, colors help you to follow a particular line.
> >
> > I don't find it easy to follow a line in a PCB, where you normally don't
> > have colors :)
> >
> > Markus
>
> I find it easier to simply click on the line and then click the parent
> in the lower window. Which I'm only mentioning b.c. others might
> not realize that it's possible.
Oh, right. I know about it, but since I don't use gitk often, I didn't
think of it.
Markus
^ permalink raw reply
* Re: t5505-remote fails on Windows
From: Jeff King @ 2009-03-19 20:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jay Soffian, Git Mailing List
In-Reply-To: <49C1F232.2090009@viscovery.net>
On Thu, Mar 19, 2009 at 08:20:18AM +0100, Johannes Sixt wrote:
> Your patch fixes it. The following change to the test case would be a good
> addition; it protects later tests from failures in earlier tests.
I'll clean up and re-submit my patch, then (once we figure out the right
API ;) ). Your patch seems reasonable, but it should be a separate
patch, I think.
-Peff
^ permalink raw reply
* Re: [EGIT] assertion failure when renaming file
From: Marcus Better @ 2009-03-19 19:45 UTC (permalink / raw)
To: git
In-Reply-To: <200903171940.21617.robin.rosenberg.lists@dewire.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robin Rosenberg wrote:
> There are some ways of corrupting a repo, i.e. the association between
> the Git provider and the project that results in wierd behaviours. The
> ones I know of are related to renaming and moving projects tracked by
> EGit, which works minus-well.
Yes, I think I moved the project once.
I also get a message about a NPE "when scanning the repository for changes" shortly after starting Eclipse:
!ENTRY org.spearce.egit.core 4 0 2009-03-19 20:22:12.776
!MESSAGE Git team provider configuration has gone missing.
!STACK 0
java.io.FileNotFoundException: /home/marcus/.workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/wrt-
widget/org.spearce.egit.core/GitProjectData.properties (Filen eller katalogen finns inte)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:137)
at org.spearce.egit.core.project.GitProjectData.load(GitProjectData.java:398)
at org.spearce.egit.core.project.GitProjectData.get(GitProjectData.java:162)
at org.spearce.egit.core.GitProvider.getData(GitProvider.java:66)
at org.spearce.egit.core.project.RepositoryMapping.getMapping(RepositoryMapping.java:235)
at org.spearce.egit.ui.internal.decorators.GitLightweightDecorator.decorate(GitLightweightDecorator.java:161)
at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:263)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:72)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:356)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:338)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:374)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:334)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
!ENTRY org.eclipse.ui.workbench 4 2 2009-03-19 20:22:12.777
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench".
!STACK 0
java.lang.NullPointerException
at org.spearce.egit.core.project.RepositoryMapping.getMapping(RepositoryMapping.java:235)
at org.spearce.egit.ui.internal.decorators.GitLightweightDecorator.decorate(GitLightweightDecorator.java:161)
at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:263)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:72)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:356)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:338)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:374)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:334)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
!ENTRY org.eclipse.ui 4 4 2009-03-19 20:22:12.777
!MESSAGE Exception in Decorator
!ENTRY org.eclipse.ui 4 4 2009-03-19 20:22:12.778
!MESSAGE java.lang.NullPointerException
!STACK 0
java.lang.NullPointerException
at org.spearce.egit.core.project.RepositoryMapping.getMapping(RepositoryMapping.java:235)
at org.spearce.egit.ui.internal.decorators.GitLightweightDecorator.decorate(GitLightweightDecorator.java:161)
at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:263)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:72)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:356)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:338)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:374)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:334)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
!ENTRY org.spearce.egit.core 4 0 2009-03-19 20:22:23.667
!MESSAGE Git team provider configuration has gone missing.
!STACK 0
java.io.FileNotFoundException: /home/marcus/.workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/wrt-
widget/org.spearce.egit.core/GitProjectData.properties (Filen eller katalogen finns inte)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:137)
at org.spearce.egit.core.project.GitProjectData.load(GitProjectData.java:398)
at org.spearce.egit.core.project.GitProjectData.get(GitProjectData.java:162)
at org.spearce.egit.core.GitProvider.getData(GitProvider.java:66)
at org.spearce.egit.core.project.RepositoryMapping.getMapping(RepositoryMapping.java:235)
at org.spearce.egit.ui.Activator$RCS.run(Activator.java:321)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
!ENTRY org.spearce.egit.ui 4 0 2009-03-19 20:22:23.710
!MESSAGE An error occurred while scanning for changes. Scanning aborted
!STACK 0
java.lang.NullPointerException
at org.spearce.egit.core.project.RepositoryMapping.getMapping(RepositoryMapping.java:235)
at org.spearce.egit.ui.Activator$RCS.run(Activator.java:321)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Could you try with a fresh workspace (you can keep the workdir as-is)?
Yes, that fixes it.
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknCoOYACgkQXjXn6TzcAQkbsgCfbRnEwiSjIo9yu9ipk9Tps6cn
Y70An2sxhtz+xtd0wTP2PODAR7jxj4Qc
=taeS
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: question about conflict resolution across multiple branches
From: Junio C Hamano @ 2009-03-19 20:11 UTC (permalink / raw)
To: William Morgan; +Cc: Git Mailing List
In-Reply-To: <1237483813-sup-5631@entry>
William Morgan <wmorgan-git@masanjin.net> writes:
> Sometimes those topic branches are remote branches on someone else's
> repo. What happens when merging a remote topic branch into next creates
> a conflict? Ideally I'd like for the topic branch author to deal with
> resolving the conflict, and leave me to my carefree maintainer existence
> of eating icecream on the couch.
Well, merging, applying and managing the conflicts between contributors is
what the maintainers do. If you push that to your contributors, you do
not have to exist ;-).
> ... In the no-conflict case, I merge their
> remote branch directly into my local next. But in the case of conflicts,
> it seems like me only way to acquire their resolution is to merge their
> next branch entirely into mine. Is that true?
It is not clear what you mean by 'their next' as the only thing you told
us is "some topic are from elsewhere". Do you mean the originator of the
topic also keeps an integration branch of his own, something similar to
your 'next'?
If that is the case, I _think_ you can fetch their next and feed the merge
you are interested in to rerere-train.sh (in contrib) before you attempt
the merge yourself. This is "I _think_" because I never used that script
myself (and it wasn't even accepted to git.git by me---I was away back
then).
> Likewise, what happens when someone sends a patch against master to the
> mailing list, and applying that patch to next creates a conflict? Is
> there any way for them to resolve the conflict, and pass that resolution
> to me?
You can tell the contributor that the area the patch touches is under an
active development that you expect to be ready soon, and ask him to redo
the patch on a specific commit on the topic.
Or you can ask the contributor to do this:
$ git fetch ;# from you
$ git checkout origin/master ;# detach to your master
$ git am the-patch
$ git merge origin/next ;# this will conflict you cannot resolve
$ edit to resolve conflicts
$ git commit ;# the resolution you cannot come up with yourself
$ git diff origin/next >fixup.patch
and send the fixup.patch to you. You would do the reverse:
$ git checkout master
$ git am the-patch
$ git checkout next
$ git merge -s ours master
$ git apply --index fixup.patch
$ git commit --amend
$ git show ;# to review what the fix-up did
Needless to say, you need to be careful when accepting such a fixup
patch.
^ permalink raw reply
* Re: Gnome chose Git
From: Jeff King @ 2009-03-19 20:14 UTC (permalink / raw)
To: Pat Notz; +Cc: Shawn O. Pearce, Michael J Gruber, Git
In-Reply-To: <1cd1989b0903190850p1a08991y754904e7799c7879@mail.gmail.com>
On Thu, Mar 19, 2009 at 09:50:39AM -0600, Pat Notz wrote:
> On Thu, Mar 19, 2009 at 9:16 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> >
> > Why are people reinventing the reflog, and core.logallrefupdates ?
> >
>
> Hmmm, lack of awareness of core.logallrefupdates in my case. Thanks
> for the pointer.
But do note that reflogs expire eventually, so you will want to also
look at gc.reflogexpire and gc.reflogexpireunreachable if you want to
keep this as an activity log forever.
-Peff
^ permalink raw reply
* Re: git am from scratch
From: Jeff King @ 2009-03-19 20:18 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <200903191609.24812.agruen@suse.de>
On Thu, Mar 19, 2009 at 04:09:24PM +0100, Andreas Gruenbacher wrote:
> lates git (e986ceb0): there is a bug in git am when trying to recreate the
> entire history of a repository:
I don't think this has ever worked in any version of git.
It might be nice to have, since it does come up once in a while, so I
suspect patches would be welcome.
But...
> When the first commit is added by hand instead, git am will import the
> rest of the mbox without problems. This is annoying because it's at
> least not immediately obvious how to recreate the initial commit with
> all the metadata.
>
> Is this easily fixed?
There are many other ways to do this. Have you tried:
- simply pulling the old repo into the new one?
- if they are not connected in real-time, creating a bundle from the
first and pulling it into the latter?
- if you want to tweak the commit data during the process, have you
tried using fast-export/fast-import rather than format-patch/am?
-Peff
^ permalink raw reply
* [PATCH] Produce a nicer output in case of sha1_object_info failures in ls-tree -l
From: Alex Riesen @ 2009-03-19 20:30 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano
Initialize the size with 0. The error message is already printed
by sha1_object_info itself. Otherwise the uninitialized size is
printed, which does not make any sense at all.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-ls-tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index fca4631..a8cdafb 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -60,7 +60,6 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
{
int retval = 0;
const char *type = blob_type;
- unsigned long size;
if (S_ISGITLINK(mode)) {
/*
@@ -91,6 +90,7 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
if (!(ls_options & LS_NAME_ONLY)) {
if (ls_options & LS_SHOW_SIZE) {
if (!strcmp(type, blob_type)) {
+ unsigned long size = 0;
sha1_object_info(sha1, &size);
printf("%06o %s %s %7lu\t", mode, type,
abbrev ? find_unique_abbrev(sha1, abbrev)
--
1.6.2.1.250.ga1458
^ permalink raw reply related
* Re: [PATCH 08/10] t2200, t7004: Avoid glob pattern that also matches files
From: Junio C Hamano @ 2009-03-19 20:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200903192052.43162.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> No, it is still useful. There is a difference if I say
>
> git add "*a*"
>
> from bash or from Windows's CMD. The latter passes the argument to git with
> the dquotes; the startup code removes them and does not expand the wildcard.
> But if bash invokes the command, bash removes the quotes, so that the startup
> code only sees *a* and does the expansion.
I can only say "yuck" :-<.
>> > In t2200, not all names that the test case is interested in exist as
>> > files at the time when 'git ls-files' is invoked. git expands "path?" to
>> > only the subset of files the exist, and only that subset was listed, so
>> > that the test failed. We now list all interesting paths explicitly.
>>
>> But that conversion misses the whole point of that particular test,
>> doesn't it? It wants to see path2 that was unmerged and existed only in
>> the index but not in the work tree has disappeared, while the similarly
>> unmerged path1 resolved after "add -u". IOW, you are not testing that
>> "add -u" notices a removal of path2 from the work tree anymore.
>
> I see. Then I'll just add path2 to the list, OK? It still passes the test.
Yeah, as we are not passing --error-unmatch to the command, it should be
the right thing to do.
^ permalink raw reply
* Re: git am from scratch
From: Andreas Gruenbacher @ 2009-03-19 20:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090319201817.GE17028@coredump.intra.peff.net>
On Thursday, 19 March 2009 21:18:17 Jeff King wrote:
> I don't think this has ever worked in any version of git.
I did find a way to help myself in the end. Still it was still a major,
unnecessary annoyance.
I ran into this problem when trying to reconstruct a project's history (after
going RCS -> CVS -> git many things were still wrong like unrelated RCS files
which ended up in the history, RCS files being moved to the Attic in the
original tree to indicate deletes [which means they will happily live on from
a CVS point of view], etc.).
The easiest way I could find how to get rid of all the mess without going
totally insane was to git-format-patch the repository, fix up the major
things in the mbox, and then recreate the history.
In the end I ended up preparing the initial commit by hand followed
by "commit -c HASH" to preserve the metadata. (The cvsimport branch had a
different commit at its tip, so I couldn't use commit --amend on that.) After
that, I git-am'ed the rest of the mbox onto that reconstructed commit. This
could have been significantly easier.
> There are many other ways to do this.
That's really not the point. Thanks though.
Andreas
^ permalink raw reply
* Re: [PATCH 00/11] Test on Windows - prequel
From: Johannes Sixt @ 2009-03-19 20:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1237410682.git.j6t@kdbg.org>
On Mittwoch, 18. März 2009, Johannes Sixt wrote:
> I'm preparing a series of patches that adjust the test suite so that it
> passes on Windows (MinGW port). This is the initial part of it. Another
> dozen or more are to follow. By splitting the series I hope to get
> earlier feedback.
>
> The series is also available from
>
> git://repo.or.cz/git/mingw/j6t.git for-junio
>
> http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=refs/heads/for-junio
I've updated the series. Would you please pick up it up from the URL
above?
The changes in particular are:
- [PATCH 02/10] test suite: Use 'say' to say something instead of...
Updated commit message.
- [PATCH 04/10] test-lib: Replace uses of $(expr ...) by POSIX...
No changes to t4013 and t5515 anymore; the next patch removes the
lines that this patch touched.
- [PATCH 05/10] test-lib: Simplify test counting.
Do not use $test_count+1 in t4013 and t5515.
- [PATCH 08/10] t2200, t7004: Avoid glob pattern that also...
Added path2 to the list.
Below is the interdiff.
-- Hannes
diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
index 652801e..5a8d52f 100755
--- a/t/t2200-add-update.sh
+++ b/t/t2200-add-update.sh
@@ -150,7 +150,7 @@ test_expect_success 'add -u resolves unmerged paths' '
echo 2 >path3 &&
echo 2 >path5 &&
git add -u &&
- git ls-files -s path1 path3 path4 path5 path6 >actual &&
+ git ls-files -s path1 path2 path3 path4 path5 path6 >actual &&
{
echo "100644 $three 0 path1"
echo "100644 $one 1 path3"
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 9c30b29..426e64e 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -101,8 +101,7 @@ do
'' | '#'*) continue ;;
esac
test=`echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g'`
- cnt=$(($test_count+1))
- pfx=`printf "%04d" $cnt`
+ pfx=`printf "%04d" $test_count`
expect="$TEST_DIRECTORY/t4013/diff.$test"
actual="$pfx-diff.$test"
diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh
index 0b39503..dbb927d 100755
--- a/t/t5515-fetch-merge-logic.sh
+++ b/t/t5515-fetch-merge-logic.sh
@@ -129,8 +129,7 @@ do
'' | '#'*) continue ;;
esac
test=`echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g'`
- cnt=$(($test_count+1))
- pfx=`printf "%04d" $cnt`
+ pfx=`printf "%04d" $test_count`
expect_f="$TEST_DIRECTORY/t5515/fetch.$test"
actual_f="$pfx-fetch.$test"
expect_r="$TEST_DIRECTORY/t5515/refs.$test"
^ permalink raw reply related
* Re: git am from scratch
From: Jeff King @ 2009-03-19 21:02 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <200903192142.49754.agruen@suse.de>
On Thu, Mar 19, 2009 at 09:42:49PM +0100, Andreas Gruenbacher wrote:
> > I don't think this has ever worked in any version of git.
> I did find a way to help myself in the end. Still it was still a major,
> unnecessary annoyance.
Sure, and that is why I suggested a patch for git-am might be welcome;
it's not the right tool for the job, but it seems to be one that people
naturally think of.
> I ran into this problem when trying to reconstruct a project's history (after
> going RCS -> CVS -> git many things were still wrong like unrelated RCS files
> which ended up in the history, RCS files being moved to the Attic in the
> original tree to indicate deletes [which means they will happily live on from
> a CVS point of view], etc.).
Yikes. Out of curiosity, what did you use to do the CVS import?
Anyway, here is a not-very-well-tested patch to get "git am" to apply on
top of an empty repository (i.e., it worked on my utterly simplistic
test case and I didn't think too hard about what else might have been
broken). Maybe it will give a good start to somebody who wants to work
on this.
---
diff --git a/git-am.sh b/git-am.sh
index d339075..bcc600d 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -290,17 +290,23 @@ else
: >"$dotest/rebasing"
else
: >"$dotest/applying"
- git update-ref ORIG_HEAD HEAD
+ if git rev-parse --quiet --verify HEAD; then
+ git update-ref ORIG_HEAD HEAD
+ else
+ rm -f "$GIT_DIR/ORIG_HEAD"
+ fi
fi
fi
case "$resolved" in
'')
- files=$(git diff-index --cached --name-only HEAD --) || exit
- if test "$files"
- then
- : >"$dotest/dirtyindex"
- die "Dirty index: cannot apply patches (dirty: $files)"
+ if git rev-parse --quiet --verify HEAD; then
+ files=$(git diff-index --cached --name-only HEAD --) || exit
+ if test "$files"
+ then
+ : >"$dotest/dirtyindex"
+ die "Dirty index: cannot apply patches (dirty: $files)"
+ fi
fi
esac
@@ -541,7 +547,7 @@ do
fi
tree=$(git write-tree) &&
- parent=$(git rev-parse --verify HEAD) &&
+ parent=$(git rev-parse --quiet --verify HEAD)
commit=$(
if test -n "$ignore_date"
then
@@ -552,7 +558,7 @@ do
GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"
export GIT_COMMITTER_DATE
fi &&
- git commit-tree $tree -p $parent <"$dotest/final-commit"
+ git commit-tree $tree ${parent:+-p $parent} <"$dotest/final-commit"
) &&
git update-ref -m "$GIT_REFLOG_ACTION: $FIRSTLINE" HEAD $commit $parent ||
stop_here $this
^ permalink raw reply related
* Re: [PATCH 2/2] Make Git respect changes to .gitattributes during checkout.
From: Junio C Hamano @ 2009-03-19 21:06 UTC (permalink / raw)
To: Kristian Amlie; +Cc: ext Junio C Hamano, git@vger.kernel.org
In-Reply-To: <49C267E3.1020205@nokia.com>
Kristian Amlie <kristian.amlie@nokia.com> writes:
> ext Junio C Hamano wrote:
> ...
>> For example, you may notice that, after making a clean checkout, one path
>> has a wrong attribute assigned to it, and may try to correct it. But how?
>>
>> $ edit .gitattributes ;# mark foo.dat as binary
>> $ rm foo.dat
>> $ git checkout foo.dat ;# make sure the new settings is correct???
>
> As far as I can see, this works without any modifications to the patch.
> Is that maybe because git_attr_set_direction() is not called if you use
> that form of checkout?
But that in itself can be seen as a bug, right? In another use case,
suppose you botched your .gitattributes in HEAD version and noticed that
foo.dat is checked out with a wrong attribute. You try to fix it like
this:
$ git reset HEAD^ .gitattributes
$ rm foo.dat
$ git checkout foo.dat
If you do not flip the direction, the one from the work tree is used which
is not what you want. If you do, then you break the other use case.
Either way, you cannot win.
In any case, I think I already queued the patch in 'pu' but without
documentation updates nor additional tests, so no need to include the
patch itself when you send in an update.
^ permalink raw reply
* [PATCH] Microoptimize strbuf_cmp
From: Alex Riesen @ 2009-03-19 21:09 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, Junio C Hamano
Make it inline and cleanup a bit. It is definitely less code
including object code, but it is not always measurably faster
(but mostly is).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
I have this patch for a long time in my tree and vaguely remember
sending it once.
strbuf.c | 12 ------------
strbuf.h | 9 ++++++++-
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index 6ed0684..e1f4db7 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -137,18 +137,6 @@ void strbuf_list_free(struct strbuf **sbs)
free(sbs);
}
-int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
-{
- int cmp;
- if (a->len < b->len) {
- cmp = memcmp(a->buf, b->buf, a->len);
- return cmp ? cmp : -1;
- } else {
- cmp = memcmp(a->buf, b->buf, b->len);
- return cmp ? cmp : a->len != b->len;
- }
-}
-
void strbuf_splice(struct strbuf *sb, size_t pos, size_t len,
const void *data, size_t dlen)
{
diff --git a/strbuf.h b/strbuf.h
index 89bd36e..df95960 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -80,11 +80,18 @@ static inline void strbuf_setlen(struct strbuf *sb, size_t len) {
extern void strbuf_trim(struct strbuf *);
extern void strbuf_rtrim(struct strbuf *);
extern void strbuf_ltrim(struct strbuf *);
-extern int strbuf_cmp(const struct strbuf *, const struct strbuf *);
extern void strbuf_tolower(struct strbuf *);
extern struct strbuf **strbuf_split(const struct strbuf *, int delim);
extern void strbuf_list_free(struct strbuf **);
+static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
+{
+ int len = a->len < b->len ? a->len: b->len;
+ int cmp = memcmp(a->buf, b->buf, len);
+ if (cmp)
+ return cmp;
+ return a->len < b->len ? -1: a->len != b->len;
+}
/*----- add data in your buffer -----*/
static inline void strbuf_addch(struct strbuf *sb, int c) {
--
1.6.2.1.250.ga1458
^ permalink raw reply related
* Re: git-svn and incorrect working copy file timestamps?
From: Derek Mahar @ 2009-03-19 21:31 UTC (permalink / raw)
To: git
In-Reply-To: <1237492452300-2505059.post@n2.nabble.com>
> Should "git svn" not preserve the file timestamps of the original commit tree
> in the working copy?
I learned from http://marc.info/?l=git&m=122783905206964&w=2 that all
Git commands do not preserve file timestamps because Git, by design,
does not record timestamps in the tree objects. So, in order to see
the last time a particular file changed, you must examine the commit
log. I guess I'll just have to get used to ignoring the working copy
file timestamps.
Derek
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) with posix semantics
From: Alex Riesen @ 2009-03-19 21:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Johannes Sixt, Jeff King, layer, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903191155300.10279@pacific.mpi-cbg.de>
So that Cygwin port can continue work around its supporting
library and get access to its faked file attributes.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Johannes Schindelin, Thu, Mar 19, 2009 11:57:01 +0100:
> On Thu, 19 Mar 2009, Alex Riesen wrote:
> > So that Cygwin port can continue work around its supporting
> > library and get access to its faked file attributes.
> >
>
> [patch not inlined: therefore you'll have to guess what I am referring to]
I resend.
> It seems quite wrong to define something for other platforms when only
> Cygwin is affected.
I know. Didn't I already said I'm sorry? I even said that it is fine
if the patches wont be applied. Just wanted to share the pain.
> I'd rather just disable WIN32_STAT for Cygwin, because otherwise, we will
> keep running into issues.
I'd rather not. The thing is just so unbelievably slow and being stuck
on it I'm just trying my damnedest to squeeze every last bit of
performance out of it.
git-compat-util.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index f09f244..c99549d 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,11 +85,16 @@
#undef _XOPEN_SOURCE
#include <grp.h>
#define _XOPEN_SOURCE 600
+static inline int posix_lstat(const char *file_name, struct stat *buf)
+{
+ return lstat(file_name, buf);
+}
#include "compat/cygwin.h"
#else
#undef _ALL_SOURCE /* AIX 5.3L defines a struct list with _ALL_SOURCE. */
#include <grp.h>
#define _ALL_SOURCE 1
+#define posix_lstat lstat
#endif
#else /* __MINGW32__ */
/* pull in Windows compatibility stuff */
--
1.6.2.1.237.g7206c6
^ permalink raw reply related
* Re: Gnome chose Git
From: demerphq @ 2009-03-19 21:40 UTC (permalink / raw)
To: Jeff King; +Cc: Git
In-Reply-To: <20090319201405.GD17028@coredump.intra.peff.net>
2009/3/19 Jeff King <peff@peff.net>:
> On Thu, Mar 19, 2009 at 09:50:39AM -0600, Pat Notz wrote:
>
>> On Thu, Mar 19, 2009 at 9:16 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> >
>> > Why are people reinventing the reflog, and core.logallrefupdates ?
>> >
>>
>> Hmmm, lack of awareness of core.logallrefupdates in my case. Thanks
>> for the pointer.
>
> But do note that reflogs expire eventually, so you will want to also
> look at gc.reflogexpire and gc.reflogexpireunreachable if you want to
> keep this as an activity log forever.
Outside of parsing the reflog directly, (which feels wrong and dirty
to me), how does one find out the times that a reflog entry was
created?
The closest thing i could find was git log -g, but that shows the time
of the commit that was switched to, not the time the reflog entry was
created. I dont see a --format pattern for it, and there doesnt seem
to be a switch to git reflog to do it. (I had initially (before
RTFM'ing) assumed that git reflog -v would show the times, but
apparently not).
If the times were easy to access then it would be much more useful as
a general logging facility.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Gnome chose Git
From: Shawn O. Pearce @ 2009-03-19 21:43 UTC (permalink / raw)
To: demerphq; +Cc: Jeff King, Git
In-Reply-To: <9b18b3110903191440w20ca9801pfb218cc4b10ea769@mail.gmail.com>
demerphq <demerphq@gmail.com> wrote:
> Outside of parsing the reflog directly, (which feels wrong and dirty
> to me), how does one find out the times that a reflog entry was
> created?
>
> The closest thing i could find was git log -g, but that shows the time
git reflog -g branch@{now}
the @{now} suffix is the magic to make it show the time.
--
Shawn.
^ permalink raw reply
* [PATCH] git clone needs to know executability of template files
From: Alex Riesen @ 2009-03-19 21:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Johannes Sixt, Jeff King, layer, Junio C Hamano
In-Reply-To: <20090319214001.GA6253@blimp.localdomain>
Use posix_lstat for template source. The copy_templates_1 needs to
know the file mode information for the copy of the template. The
copying of the executable bit always work on POSIX systems and
sometimes even on Cygwin.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-init-db.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index ee3911f..0b6dc16 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -66,7 +66,7 @@ static void copy_templates_1(char *path, int baselen,
else
exists = 1;
- if (lstat(template, &st_template))
+ if (posix_lstat(template, &st_template))
die("cannot stat template %s", template);
if (S_ISDIR(st_template.st_mode)) {
--
1.6.2.1.237.g7206c6
^ permalink raw reply related
* Re: Gnome chose Git
From: Shawn O. Pearce @ 2009-03-19 21:44 UTC (permalink / raw)
To: demerphq; +Cc: Jeff King, Git
In-Reply-To: <20090319214317.GU23521@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> demerphq <demerphq@gmail.com> wrote:
> > Outside of parsing the reflog directly, (which feels wrong and dirty
> > to me), how does one find out the times that a reflog entry was
> > created?
> >
> > The closest thing i could find was git log -g, but that shows the time
>
> git reflog -g branch@{now}
Arrgh, I of course actually meant
git log -g branch@{now}
> the @{now} suffix is the magic to make it show the time.
--
Shawn.
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Nanako Shiraishi @ 2009-03-19 21:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Allan Caffee, git
In-Reply-To: <alpine.DEB.1.00.0903191831590.6357@intel-tinevez-2-302>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> I'd start like this:
>
> enum color_name {
> COLOR_RESET,
> COLOR_RED,
> COLOR_GREEN,
> COLOR_YELLOW,
> COLOR_BLUE,
> COLOR_MAGENTA,
> COLOR_CYAN,
> COLOR_WHITE
> };
Looking for "COLOR_RED" in the archive gives:
http://article.gmane.org/gmane.comp.version-control.git/109676
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Gnome chose Git
From: demerphq @ 2009-03-19 21:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, Git
In-Reply-To: <20090319214317.GU23521@spearce.org>
2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> demerphq <demerphq@gmail.com> wrote:
>> Outside of parsing the reflog directly, (which feels wrong and dirty
>> to me), how does one find out the times that a reflog entry was
>> created?
>>
>> The closest thing i could find was git log -g, but that shows the time
>
> git reflog -g branch@{now}
>
> the @{now} suffix is the magic to make it show the time.
Ah cool. Its not documented but that at least would have sorted my
immediate needs.
But for a logging tool it would be nice to get something like:
2009-03-19 21:46 > de9b652... HEAD@{0}: commit: pod/perlreftut.pod:
keep example in tune with the times
2009-03-19 21:44 > 53102b2... HEAD@{1}: HEAD^: updating HEAD
2009-03-19 21:40 > a9a8f59... HEAD@{2}: commit: must stay contemporary
instead of:
$ git reflog -g HEAD@{now}
de9b652... HEAD@{57 minutes ago}: commit: pod/perlreftut.pod: keep
example in tune with the times
53102b2... HEAD@{61 minutes ago}: HEAD^: updating HEAD
a9a8f59... HEAD@{61 minutes ago}: commit: must stay contemporary
But thanks a lot for the info. I take this is documented in a newer
release than i currently have?
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Gnome chose Git
From: demerphq @ 2009-03-19 21:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, Git
In-Reply-To: <20090319214432.GV23521@spearce.org>
2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> "Shawn O. Pearce" <spearce@spearce.org> wrote:
>> demerphq <demerphq@gmail.com> wrote:
>> > Outside of parsing the reflog directly, (which feels wrong and dirty
>> > to me), how does one find out the times that a reflog entry was
>> > created?
>> >
>> > The closest thing i could find was git log -g, but that shows the time
>>
>> git reflog -g branch@{now}
>
> Arrgh, I of course actually meant
>
> git log -g branch@{now}
>
>> the @{now} suffix is the magic to make it show the time.
Ah! Much nicer! Thanks.
Is there by any chance any way to set the date format it uses to
something more suitable for machine processing?
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Gnome chose Git
From: Shawn O. Pearce @ 2009-03-19 21:53 UTC (permalink / raw)
To: demerphq; +Cc: Jeff King, Git
In-Reply-To: <9b18b3110903191451u56bbee7biac3a1fee4a36b71d@mail.gmail.com>
demerphq <demerphq@gmail.com> wrote:
> 2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> > "Shawn O. Pearce" <spearce@spearce.org> wrote:
> >
> > git log -g branch@{now}
>
> Ah! Much nicer! Thanks.
>
> Is there by any chance any way to set the date format it uses to
> something more suitable for machine processing?
I don't think so. If you want to machine process it, why not
just read the reflog directly? Its a really simple format.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Produce a nicer output in case of sha1_object_info failures in ls-tree -l
From: Junio C Hamano @ 2009-03-19 21:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Jakub Narebski
In-Reply-To: <20090319203002.GA31014@blimp.localdomain>
Alex Riesen <raa.lkml@gmail.com> writes:
> Initialize the size with 0. The error message is already printed
> by sha1_object_info itself. Otherwise the uninitialized size is
> printed, which does not make any sense at all.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> builtin-ls-tree.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
> index fca4631..a8cdafb 100644
> --- a/builtin-ls-tree.c
> +++ b/builtin-ls-tree.c
> @@ -60,7 +60,6 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
> {
> int retval = 0;
> const char *type = blob_type;
> - unsigned long size;
>
> if (S_ISGITLINK(mode)) {
> /*
> @@ -91,6 +90,7 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
> if (!(ls_options & LS_NAME_ONLY)) {
> if (ls_options & LS_SHOW_SIZE) {
> if (!strcmp(type, blob_type)) {
> + unsigned long size = 0;
> sha1_object_info(sha1, &size);
> printf("%06o %s %s %7lu\t", mode, type,
> abbrev ? find_unique_abbrev(sha1, abbrev)
Hmm, shouldn't you be checking the return value from sha1_object_info()
and skipping the printf() altogether instead?
^ 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