* Re: [PATCH v3] Threaded grep
From: Fredrik Kuivinen @ 2010-01-19 7:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.1001180947140.13231@localhost.localdomain>
On Mon, Jan 18, 2010 at 10:05:19AM -0800, Linus Torvalds wrote:
> On my machine (4 cores with HT, so 8 threads total), I get the
> following:
>
> [ Note: the --no-ext-grep is because I'm comparing with a git that has
> the original grep optimization, but hasn't removed the external grep
> functionality yet. I just used the same command line when then comparing
> to next+your patch, so don't mind it.
>
> Also, the three examples are chosen to be: "trivial single match",
> "regex single match", and "trivial lots of matches" ]
You may be testing slightly different things: next has 885d211 (grep:
rip out pessimization to use fixmatch()) and bbc09c2 (grep: rip out
support for external grep) was added before. So next+patch uses
regexec and the version with support for external greps uses
strstr. IIRC strstr was a bit faster than regexec on your
box. However, this only explains a small part of the results you are
seeing.
>
> Before (all best-of-five), with the non-threaded internal grep:
>
> - git grep --no-ext-grep qwerty
>
> real 0m0.311s
> user 0m0.164s
> sys 0m0.144s
>
> - git grep --no-ext-grep qwerty.*as
>
> real 0m0.555s
> user 0m0.416s
> sys 0m0.132s
>
> - git grep --no-ext-grep function
>
> real 0m0.461s
> user 0m0.276s
> sys 0m0.180s
>
> After, with threading:
>
> - git grep --no-ext-grep qwerty
>
> real 0m0.152s
> user 0m0.788s
> sys 0m0.212s
>
> - git grep --no-ext-grep qwerty.*as
>
> real 0m0.148s
> user 0m0.724s
> sys 0m0.284s
>
> - git grep --no-ext-grep function
>
> real 0m0.241s
> user 0m1.436s
> sys 0m0.216s
>
> so now it's a clear win in all cases. And as you'd expect, the "complex
> case with single output" is the one that wins most, since it's the one
> that should have the most CPU usage, with the least synchronization.
>
> That said, it still does waste quite a bit of time doing this, and while
> it almost doubles performance in the last case too, it does so at the cost
> of quite a bit of overhead.
>
> (Some overhead is natural, especially since I have HT. Running two threads
> on the same core does _not_ give double the performance, so the CPU time
> almost doubling - because the threads themselves run slower - is not
> unexpected. It's when the CPU time more than quadruples that I suspect
> that it could be improved a bit).
I haven't seen this overhead during my tests. But I'm _guessing_ that
the problem is that the mutex grep_lock is held while the result is
written to stdout. So when we are writing, no significant amount of
work can be done by any thread. Here is a patch to fix this (applies
on to of v3).
diff --git a/builtin-grep.c b/builtin-grep.c
index 8fca7a6..422b0ec 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -139,21 +139,48 @@ static int grep_file_async(struct grep_opt *opt, char *name,
return 0;
}
+/* Mark the work_item as done. The function guarantees that w->done is
+ * set to 1 and that if w is included in a prefix of the range
+ * [todo_done, todo_start) where each work_item has .done == 1, then
+ * w->out will eventually be written to stdout. The writing is done
+ * either by this thread or by the thread which has set 'writing' to
+ * 1.
+ */
static void work_done(struct work_item *w)
{
- int old_done;
+ /* 1 if there is a thread which is writing data to stdout and
+ 0 otherwise. */
+ static int writing = 0;
+ int old_done, write_idx, write_to;
pthread_mutex_lock(&grep_lock);
w->done = 1;
old_done = todo_done;
- for(; todo[todo_done].done && todo_done != todo_start;
- todo_done = (todo_done+1) % ARRAY_SIZE(todo)) {
- w = &todo[todo_done];
- write_or_die(1, w->out.buf, w->out.len);
- if (w->type == WORK_BUF)
- free(w->buf);
-
- free(w->name);
+
+ /* We need a loop here if todo_start is changed while we write
+ * some data. */
+ while (!writing && todo[todo_done].done && todo_done != todo_start) {
+ write_idx = todo_done;
+ write_to = todo_start;
+ writing = 1;
+
+ /* Unlock the mutex while we write the data. This is
+ * safe as writing == 1 and hence there is at most one
+ * thread which writes data at any time. */
+ pthread_mutex_unlock(&grep_lock);
+ for(; todo[write_idx].done && write_idx != write_to;
+ write_idx = (write_idx+1) % ARRAY_SIZE(todo)) {
+ w = &todo[write_idx];
+ write_or_die(1, w->out.buf, w->out.len);
+ if (w->type == WORK_BUF)
+ free(w->buf);
+
+ free(w->name);
+ }
+
+ pthread_mutex_lock(&grep_lock);
+ writing = 0;
+ todo_done = write_idx;
}
if (old_done != todo_done)
^ permalink raw reply related
* Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346
From: Gustaf Hendeby @ 2010-01-19 8:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jacob Helwig, git, Jens.Lehmann
In-Reply-To: <4B555BA1.90605@viscovery.net>
Johannes Sixt wrote:
> Jacob Helwig schrieb:
>> If there is no output from git status in the submodule, then git
>> status in the superproject shows the submodule as being clean.
>> However, if there is _any_ output from git status (untracked files,
>> modified files, deleted files, new files), then the superproject shows
>> the submodule as being dirty.
>
> But isn't it a bug that a submodule is considered dirty just because an
> untracked file appears?
I prefer the old behavior, and find the new one a bit unintuitive and I
suspect it will hit more people than just me once the change ends up on
master. Unfortunately, the response yesterday pointed in the direction
of this being a wanted feature. I think the change of behavior should
at least be mentioned in the release note.
/Gustaf
^ permalink raw reply
* Re: [PATCH v2] Performance optimization for detection of modified submodules
From: Jens Lehmann @ 2010-01-19 8:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v1vhmg975.fsf@alter.siamese.dyndns.org>
Am 19.01.2010 02:44, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> - Changed the type of the new dirty_submodule flags to unsigned.
>
> Why? An unsigned used in place of a bool raises an eyebrow as it is more
> common to use "int" (the most natural type on the platform). Going
> against tradition makes readers waste time wondering if there were some
> other reason why the code couldn't use "int" and had to use "unsigned"
> (e.g. "Hmmpphh, it looked like a mere boolean but the use of 'unsigned'
> suggests there might be something deeper going on. Is this used as a
> bitfield? Does this count and cannot go negative?").
I am working on a subsequent patch where dirty_submodule is used as a
bitfield to store more detailed information about the dirtiness. That is
then used by "git diff --submodule" to tell the user if the submodule
contains untracked and/or modified files.
But i can revert that part if you want.
>> + if (S_ISGITLINK(ce->ce_mode)
>> + && (!changed || (revs->diffopt.output_format & DIFF_FORMAT_PATCH))
>> + && is_submodule_modified(ce->name)) {
>> + changed = 1;
>> + dirty_submodule = 1;
>> + }
>
> If the index records a submodule commit, and the commit checked out in the
> submodule is different from that commit, ce_compare_gitlink() called from
> ce_match_stat() would have already said "changed". If we want "-dirty",
> we need to call is_submodule_modified(), but otherwise we don't. Looks
> good.
>
> Does DIFF_FORMAT_PATCH cover all cases where we may want a reliable value
> in "dirty_submodule" here? Should use of "--submodule=log" affect this
> decision?
In my testing "git diff --submodule=log" has DIFF_FORMAT_PATCH set too.
>> @@ -204,16 +209,18 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
>> static void diff_index_show_file(struct rev_info *revs,
>> const char *prefix,
>> struct cache_entry *ce,
>> - const unsigned char *sha1, unsigned int mode)
>> + const unsigned char *sha1, unsigned int mode,
>> + unsigned dirty_submodule)
>> {
>> diff_addremove(&revs->diffopt, prefix[0], mode,
>> - sha1, ce->name);
>> + sha1, ce->name, dirty_submodule);
>
> Mental note to myself. prefix[0] is either '-' (removed from the work
> tree) or '+' (added to the work tree). Added submodule could be
> immediately dirty.
Should i add a comment there?
>> diff --git a/diffcore.h b/diffcore.h
>> index 5b63458..66687c3 100644
>> --- a/diffcore.h
>> +++ b/diffcore.h
>> @@ -42,6 +42,7 @@ struct diff_filespec {
>> #define DIFF_FILE_VALID(spec) (((spec)->mode) != 0)
>> unsigned should_free : 1; /* data should be free()'ed */
>> unsigned should_munmap : 1; /* data should be munmap()'ed */
>> + unsigned dirty_submodule : 1; /* For submodules: its work tree is dirty */
>
> By the way, we might want to consolidate these bitfields into a single
>
> unsigned should_free:1,
> should_munmap:1,
> dirty_submodule:1;
>
> in a separate clean-up patch, after all the dust settles.
Okay.
^ permalink raw reply
* Андрей Сапик добавил Вас в друзья на сайте ВКонтакте.ру
From: ВКонтакте.ру @ 2010-01-19 8:45 UTC (permalink / raw)
To: git
git,
Андрей Сапик добавил Вас в друзья на сайте ВКонтакте.ру
Вы можете зайти на сайт и просмотреть страницы Ваших друзей, используя
Ваш e-mail и автоматически созданный пароль: mc4xaMNz
ВКонтакте.ру - сайт, который ежедневно позволяет десяткам миллионов людей находить старых друзей и оставаться с ними на связи, делиться фотографиями
и событиями из жизни.
Чтобы войти на сайт, пройдите по ссылке:
http://vkontakte.ru/login.php?regemail=git@vger.kernel.org#mc4xaMNz
Внимание: Ваша регистрация не будет активирована, если Вы проигнорируете
это приглашение.
Желаем удачи!
С уважением,
Администрация ВКонтакте.ру
^ permalink raw reply
* [PATCH] Fix errors in t6018
From: Ilari Liusvaara @ 2010-01-19 9:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <20100119065609.GB3946@coredump.intra.peff.net>
Fix errors and shortcomings in t6018 (the rev-parse --namespace test):
1) Some tests were missing &&'s, leading too possibly missing failures
2) Some tests used incorrect commands (didn't test what they were
suppoed to)
3) Some test used 'cmp' instead of 'test_cmp'
4) Tests only tested output up to permutation
Fix these errors in t6018.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
This can be appiled on top of rev-parse --namespace patch v3 or this
can be squashed to that patch.
t/t6018-rev-list-namespace.sh | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/t/t6018-rev-list-namespace.sh b/t/t6018-rev-list-namespace.sh
index 6bb562a..70c8a83 100755
--- a/t/t6018-rev-list-namespace.sh
+++ b/t/t6018-rev-list-namespace.sh
@@ -14,23 +14,23 @@ commit () {
compare () {
# Split arguments on whitespace.
- git $1 $2 | sort >expected &&
- git $1 $3 | sort >actual &&
- cmp expected actual
+ git $1 $2 >expected &&
+ git $1 $3 >actual &&
+ test_cmp expected actual
}
test_expect_success 'setup' '
commit master &&
- git checkout -b subspace/one master
+ git checkout -b subspace/one master &&
commit one &&
- git checkout -b subspace/two master
+ git checkout -b subspace/two master &&
commit two &&
- git checkout -b subspace-x master
+ git checkout -b subspace-x master &&
commit subspace-x &&
- git checkout -b other/three master
+ git checkout -b other/three master &&
commit three &&
- git checkout -b someref master
+ git checkout -b someref master &&
commit some &&
git checkout master &&
commit master2
@@ -68,7 +68,7 @@ test_expect_success 'rev-parse --namespace=heads/someref master' '
test_expect_success 'rev-parse --namespace=heads' '
- compare rev-parse "subspace/one subspace/two other/three subspace-x master someref" "--namespace=heads"
+ compare rev-parse "master other/three someref subspace-x subspace/one subspace/two" "--namespace=heads"
'
@@ -92,19 +92,19 @@ test_expect_success 'rev-list --namespace=heads/subspace' '
test_expect_success 'rev-list --namespace=heads/someref master' '
- compare rev-parse "master" "--namespace=heads/someref master"
+ compare rev-list "master" "--namespace=heads/someref master"
'
test_expect_success 'rev-list --namespace=heads/subspace --namespace=heads/other' '
- compare rev-parse "subspace/one subspace/two other/three" "--namespace=heads/subspace --namespace=heads/other"
+ compare rev-list "subspace/one subspace/two other/three" "--namespace=heads/subspace --namespace=heads/other"
'
test_expect_success 'rev-list --namespace=heads' '
- compare rev-parse "subspace/one subspace/two other/three subspace-x master someref" "--namespace=heads"
+ compare rev-list "master other/three someref subspace-x subspace/one subspace/two" "--namespace=heads"
'
--
1.6.6.199.gff4b0
^ permalink raw reply related
* git-describe recognize modified files
From: tzachi perelstein @ 2010-01-19 9:53 UTC (permalink / raw)
To: git
I use git-describe to form a build version automatically. This allows me
to deliver temporary builds for testing without having to make manual
tags for them. The only thing that bothers me about this is that from
the output of git-describe I cannot tell if there are some modified
files in tree or not. In both cases I will get the same version.
To solve this issue, in addition to git-describe, my do_version script
also run git-status, and if there are "modified:" files then it
concatenates the string "+dirty" to output of git-describe. This way by
looking at the version I'm able to know whether a specific version is
valid (checkout-able) or not.
It would be nice to have this option supported in git-describe IMO. I'm willing to implement that and submit a patch for review, but I'd like to hear your opinion first.
Tzachi
^ permalink raw reply
* Re: git-describe recognize modified files
From: Johannes Schindelin @ 2010-01-19 10:35 UTC (permalink / raw)
To: tzachi perelstein; +Cc: git
In-Reply-To: <829260.92036.qm@web45202.mail.sp1.yahoo.com>
Hi,
On Tue, 19 Jan 2010, tzachi perelstein wrote:
> I use git-describe to form a build version automatically. This allows me
> to deliver temporary builds for testing without having to make manual
> tags for them. The only thing that bothers me about this is that from
> the output of git-describe I cannot tell if there are some modified
> files in tree or not. In both cases I will get the same version.
>
> To solve this issue, in addition to git-describe, my do_version script
> also run git-status, and if there are "modified:" files then it
> concatenates the string "+dirty" to output of git-describe.
The problem is that this does not describe the exact version you used very
well. If you are really serious about describing the exact state you
described, make a tag (committing the changes to a detached HEAD first, if
you do not want the changes in a real branch).
Ciao,
Dscho
^ permalink raw reply
* How to resolve conflict: Moved away vs. created new file with same name
From: Johannes Schneider @ 2010-01-19 11:10 UTC (permalink / raw)
To: git
Hi,
I had the following merge problem that I could not solve.
TopicA:
created a directory "client" containing a pom.xml and several source files.
TopicB:
created a directory "client" containing a pom.xml (different file than
the one in TopicA).
Created several subdirectories (client1, client2).
You get the idea? I introduce several different clients and want them to
be stored within one directory. But I did not have this idea when I have
started TopicA.
So I am trying to mimic the change in TopicA:
cd client
mkdir client3
mv pom.xml client3
mv src client3
...commit...
Okay, so far so good. Now I try to merge TopicA and TopicB which fails.
Of course Git doesn't understand that "client/pom.xml" in TopicA and
TopicB are not related.
I want to end with to the file from TopicA ending in
"client/client3/pom.xml" and the file from TopicB in "client/pom.xml".
I don't blame Git for not knowing what I want. I just wanna ask how I
should tell Git what I want? Any hints?
Thanks,
Johannes
^ permalink raw reply
* Re: How to resolve conflict: Moved away vs. created new file with same name
From: Johannes Sixt @ 2010-01-19 11:55 UTC (permalink / raw)
To: Johannes Schneider; +Cc: git
In-Reply-To: <4B559328.2010206@cedarsoft.com>
Johannes Schneider schrieb:
> TopicA:
>
> created a directory "client" containing a pom.xml and several source files.
>
>
> TopicB:
>
> created a directory "client" containing a pom.xml (different file than
> the one in TopicA).
> Created several subdirectories (client1, client2).
>
> ...
> So I am trying to mimic the change in TopicA:
>
> cd client
> mkdir client3
> mv pom.xml client3
> mv src client3
> ...commit...
Did you do this during the merge? If not, go back to TopicA and redo it;
then you avoid the conflict during the merge.
> Okay, so far so good. Now I try to merge TopicA and TopicB which fails.
> Of course Git doesn't understand that "client/pom.xml" in TopicA and
> TopicB are not related.
> I want to end with to the file from TopicA ending in
> "client/client3/pom.xml" and the file from TopicB in "client/pom.xml".
During the merge without the fixup suggested above:
git rm -f client/client3/pom.xml
git checkout TopicA -- client/pom.xml
git mv client/pom.xml client/client3/pom.xml
git checkout TopicB -- client/pom.xml
but it leaves you with an ugly history, and it would be far better to fix
up TopicA before the merge.
-- Hannes
^ permalink raw reply
* Re: Branch merge bug
From: Michael J Gruber @ 2010-01-19 12:07 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <f3271551001182322p86a02d8p8b9ceb49e930d333@mail.gmail.com>
Ramkumar Ramachandra venit, vidit, dixit 19.01.2010 08:22:
> A friend showed me this reduced test case. It seems to work fine with
> bzr and hg. Is this a git bug?
It's not a bug, it's a feature. Git does not track renames. It tracks
content and detects renames when necessary. Knowing that it is easy to
construct examples on which git merge "fails", such as the one you present.
A file which is changed completely is not a renamed file, it's a new one
under the same name. Whether the committer meant to create a new file
(using the same name by accident or on purpose) or whether it is really
a heavily modified and renamed version - who knows? Git doesn't, and
cannot, and it leaves that decision up to you.
If you really mean to modify and rename an existing file, then tell Git so:
git mv fil fila
git commit -m 'we need a new name'
instead of your 'git rm fil' will record your intentions (not only for
Git, but also for everyone else reading your log, such as you a year
from now) and will make the merge succeed.
Michael
^ permalink raw reply
* Re: git-describe recognize modified files
From: Andreas Krey @ 2010-01-19 12:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: tzachi perelstein, git
In-Reply-To: <alpine.DEB.1.00.1001191134130.3164@intel-tinevez-2-302>
On Tue, 19 Jan 2010 11:35:41 +0000, Johannes Schindelin wrote:
...
> > To solve this issue, in addition to git-describe, my do_version script
> > also run git-status, and if there are "modified:" files then it
> > concatenates the string "+dirty" to output of git-describe.
>
> The problem is that this does not describe the exact version you used very
> well.
I (and probably the original poster) don't care that much; for me the
important information is that the binary (or whatever) was not built
from the exact committed state. Thus the question is whether the
second two lines of
BUILDINFO=git-`git describe --abbrev=16 --always HEAD 2>/dev/null`
git update-index -q --refresh
test -z "`git diff-index --name-only HEAD --`" || BUILDINFO="$BUILDINFO.dirty"
(after GIT-VERSION-GEN) are worth to be integrated into git-describe?
(And whether it should also say '.dirty'
when there are untracked files present.
Or either for submodules.)
Andreas
^ permalink raw reply
* Re: Branch merge bug
From: Andreas Krey @ 2010-01-19 12:39 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Ramkumar Ramachandra, git
In-Reply-To: <4B55A080.7010705@drmicha.warpmail.net>
On Tue, 19 Jan 2010 13:07:28 +0000, Michael J Gruber wrote:
...
> If you really mean to modify and rename an existing file, then tell Git so:
>
> git mv fil fila
> git commit -m 'we need a new name'
>
> instead of your 'git rm fil' will record your intentions (not only for
> Git, but also for everyone else reading your log, such as you a year
> from now) and will make the merge succeed.
The intention would only be known informally in the commit message,
as 'git mv' just removes the old and adds the new file, and still
leave the work to the rename detection.
Indeed, changing
>: git rm fil
>: echo asjhdajkhsdkajhs >fila
>: git add fila
to
>: git mv fil fila
>: echo asjhdajkhsdkajhs >fila
>: git add fila
and even to
>: git mv fil fila
>: git cm 'other mv'
>: echo asjhdajkhsdkajhs >fila
>: git add fila
still gives the same rename/delete conflict because the rename
detection does not look at every single commit but only at
the total changes.
Which is actually good; when someone does
cp prog.c prog.cpp
git add prog.cpp && git commit
vi prog.cpp --make-compile-again && git commit -a
git rm prog.c && git commit
it is still seen as a rename prog.c->prog.cpp even though both
existed in parallel for some commits.
Andreas
^ permalink raw reply
* Re: git-describe recognize modified files
From: Jakub Narebski @ 2010-01-19 12:49 UTC (permalink / raw)
To: Andreas Krey; +Cc: Johannes Schindelin, tzachi perelstein, git
In-Reply-To: <20100119122122.GA28667@inner.home.ulmdo.de>
Andreas Krey <a.krey@gmx.de> writes:
> On Tue, 19 Jan 2010 11:35:41 +0000, Johannes Schindelin wrote:
> ...
> > > To solve this issue, in addition to git-describe, my do_version script
> > > also run git-status, and if there are "modified:" files then it
> > > concatenates the string "+dirty" to output of git-describe.
> >
> > The problem is that this does not describe the exact version you used very
> > well.
>
> I (and probably the original poster) don't care that much; for me the
> important information is that the binary (or whatever) was not built
> from the exact committed state. Thus the question is whether the
> second two lines of
>
> BUILDINFO=git-`git describe --abbrev=16 --always HEAD 2>/dev/null`
> git update-index -q --refresh
> test -z "`git diff-index --name-only HEAD --`" || BUILDINFO="$BUILDINFO.dirty"
>
> (after GIT-VERSION-GEN) are worth to be integrated into git-describe?
>
> (And whether it should also say '.dirty'
> when there are untracked files present.
> Or either for submodules.)
FYI it is integrated in git-describe since
9f67d2e (Teach "git describe" --dirty option, 2009-10-21)
by Jean Privat (it should be present in 1.6.6, IIRC).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-describe recognize modified files
From: tzachi perelstein @ 2010-01-19 12:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.1001191134130.3164@intel-tinevez-2-302>
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> To: tzachi perelstein <tzachi_perelstein@yahoo.com>
> Cc: git@vger.kernel.org
> Sent: Tue, January 19, 2010 12:35:41 PM
> Subject: Re: git-describe recognize modified files
>
> Hi,
>
> On Tue, 19 Jan 2010, tzachi perelstein wrote:
>
> > I use git-describe to form a build version automatically. This allows me
> > to deliver temporary builds for testing without having to make manual
> > tags for them. The only thing that bothers me about this is that from
> > the output of git-describe I cannot tell if there are some modified
> > files in tree or not. In both cases I will get the same version.
> >
> > To solve this issue, in addition to git-describe, my do_version script
> > also run git-status, and if there are "modified:" files then it
> > concatenates the string "+dirty" to output of git-describe.
>
> The problem is that this does not describe the exact version you used very
> well. If you are really serious about describing the exact state you
> described, make a tag (committing the changes to a detached HEAD first, if
> you do not want the changes in a real branch).
>
Well yes, this is valid, but you will end up with a tag for every build... this goes way too far.
Consider the case where you have no modified files in your tree. The output of git-describe at some given point is 'v1.0.0-2-g123457' and during the build it becomes the build version. Now you make some changes, but before committing them you build, install, and run a test. During the second build, the output of git-describe remains the same 'v1.0.0-2-g123457' although it represent two different trees. This behavior looks like somewhat incomplete to me. It sounds reasonable to me to let git-describe have the option of indicating about modified files in tree, say 'v1.0.0-2-g123457-modified' or something similar. While 'v1.0.0-2-g123457' is something you and git can refer to (i.e. checkout), 'v1.0.0-2-g123457-modified' is not. By adding the "-modified" string, git tells you explicitly that it cannot fully describe the exact tree you're using.
^ permalink raw reply
* Re: git-describe recognize modified files
From: tzachi perelstein @ 2010-01-19 13:07 UTC (permalink / raw)
To: Jakub Narebski, Andreas Krey; +Cc: Johannes Schindelin, git
In-Reply-To: <m34omiclap.fsf@localhost.localdomain>
> FYI it is integrated in git-describe since
>
> 9f67d2e (Teach "git describe" --dirty option, 2009-10-21)
>
> by Jean Privat (it should be present in 1.6.6, IIRC).
>
Good news :)
Thanks
^ permalink raw reply
* Re: Branch merge bug
From: Ramkumar Ramachandra @ 2010-01-19 13:22 UTC (permalink / raw)
To: Andreas Krey; +Cc: Michael J Gruber, git
In-Reply-To: <20100119123915.GB28667@inner.home.ulmdo.de>
Right. Thanks for clearing that up for me.
^ permalink raw reply
* Feature idea: Ignore content
From: Ramkumar Ramachandra @ 2010-01-19 13:29 UTC (permalink / raw)
To: git
Hi,
Often, I find that I need to track a file which contains a small
portion I don't want to track (read: line with a password). Instead of
moving that out to a separate file and ignoring that file, is it a
good idea to add a feature to Git to allow ignoring content instead of
whole files? Since Git by nature tracks content, this shouldn't be too
hard to implement, right?
^ permalink raw reply
* Re: Branch merge bug
From: Michael J Gruber @ 2010-01-19 13:58 UTC (permalink / raw)
To: Andreas Krey; +Cc: Ramkumar Ramachandra, git
In-Reply-To: <20100119123915.GB28667@inner.home.ulmdo.de>
Andreas Krey venit, vidit, dixit 19.01.2010 13:39:
> On Tue, 19 Jan 2010 13:07:28 +0000, Michael J Gruber wrote:
> ...
>> If you really mean to modify and rename an existing file, then tell Git so:
>>
>> git mv fil fila
>> git commit -m 'we need a new name'
>>
>> instead of your 'git rm fil' will record your intentions (not only for
>> Git, but also for everyone else reading your log, such as you a year
>> from now) and will make the merge succeed.
>
> The intention would only be known informally in the commit message,
> as 'git mv' just removes the old and adds the new file, and still
> leave the work to the rename detection.
>
> Indeed, changing
> >: git rm fil
> >: echo asjhdajkhsdkajhs >fila
> >: git add fila
> to
> >: git mv fil fila
> >: echo asjhdajkhsdkajhs >fila
> >: git add fila
> and even to
> >: git mv fil fila
> >: git cm 'other mv'
> >: echo asjhdajkhsdkajhs >fila
> >: git add fila
> still gives the same rename/delete conflict because the rename
> detection does not look at every single commit but only at
> the total changes.
Well, the solution I proposed (mv + commit rather than rm) certainly
works for me, I tested it before. I have diff.renames=copies in my
config but I don't think it should matter.
Michael
^ permalink raw reply
* Re: Feature idea: Ignore content
From: Peter Krefting @ 2010-01-19 14:05 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git Mailing List
In-Reply-To: <f3271551001190529h389ce321k52dcca6b03e4e8f0@mail.gmail.com>
Ramkumar Ramachandra:
> Instead of moving that out to a separate file and ignoring that file, is
> it a good idea to add a feature to Git to allow ignoring content instead
> of whole files?
You should be able to do that by setting up a filter. Please see
gitattributes(5) for more information (search for "filter").
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346
From: Jacob Helwig @ 2010-01-19 14:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Gustaf Hendeby, git, Jens.Lehmann
In-Reply-To: <4B555BA1.90605@viscovery.net>
On Mon, Jan 18, 2010 at 23:13, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Jacob Helwig schrieb:
>> If there is no output from git status in the submodule, then git
>> status in the superproject shows the submodule as being clean.
>> However, if there is _any_ output from git status (untracked files,
>> modified files, deleted files, new files), then the superproject shows
>> the submodule as being dirty.
>
> But isn't it a bug that a submodule is considered dirty just because an
> untracked file appears?
>
> -- Hannes
>
I wouldn't consider it a bug, but that's specific to my use case of submodules.
At work, we're using them for shared Perl libraries between projects.
The only reason we have for creating new, untracked files in the
submodule is that we're adding new library code. Having the submodule
show up as dirty for us is another safety towards not forgetting to
commit & push out this new code.
I agree that this isn't intuitive given how status normally handles
files in projects, but it makes sense (to me, anyway), when dealing
with library code.
Should this be the default behavior for everyone? I can't say. If
it's not, I would at least like it to be behavior that you can opt-in
to.
-Jacob
^ permalink raw reply
* Push to origin failed
From: Johannes Schneider @ 2010-01-19 14:41 UTC (permalink / raw)
To: git
Hi,
my Hudson isn't able to push master back to origin under some special
circumstances:
The git-push command failed.
Command output:
To ssh://git.cedarsoft.com/git/com.cedarsoft.open
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to
'ssh://git.cedarsoft.com/git/com.cedarsoft.open'
When I delete the .git directory and let Hudson do the same thing again,
everything works well.
Of course I have verified the obvious first:
git push
To ssh://git.cedarsoft.com/git/com.cedarsoft.open
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to
'ssh://git.cedarsoft.com/git/com.cedarsoft.open'
git log
commit 1e3d3d2c1a38cae75d60bbcd8bc739ed00597ad3
Author: Hudson <hudson@cedarsoft.com>
Date: Tue Jan 19 15:25:10 2010 +0100
[maven-release-plugin] prepare release open-2.0.6
commit 9b8b395a4f9f725aa82be61474835fd1f7d009a7
Author: Johannes Schneider <js@cedarsoft.com>
Date: Tue Jan 19 12:00:14 2010 +0100
license-plugin: added excludes
On my local computer, I have called "git pull" on master and then tried
git log with that result:
git log
commit 9b8b395a4f9f725aa82be61474835fd1f7d009a7
Author: Johannes Schneider <js@cedarsoft.com>
Date: Tue Jan 19 12:00:14 2010 +0100
license-plugin: added excludes
So I don't see any reason why the push failed. Any ideas? How can I
investigate this issue further?
Obviously I don't know enough about Git, so any hints are welcome...
Thanks,
Johannes
^ permalink raw reply
* Re: How to resolve conflict: Moved away vs. created new file with same name
From: Johannes Sixt @ 2010-01-19 14:55 UTC (permalink / raw)
To: Johannes Schneider; +Cc: Git Mailing List
In-Reply-To: <4B55C481.90406@cedarsoft.com>
Please keep the discussion on the list. I'm not your personal support dude.
Johannes Schneider schrieb:
> On 01/19/2010 12:55 PM, Johannes Sixt wrote:
>>> So I am trying to mimic the change in TopicA:
>>>
>>> cd client
>>> mkdir client3
>>> mv pom.xml client3
>>> mv src client3
>>> ...commit...
>>
>> Did you do this during the merge? If not, go back to TopicA and redo it;
>> then you avoid the conflict during the merge.
>
> Yes, I have done this in TopicA *before* the merge. I knew that there
> will be conflicting directories and tried to clean that up before.
>
>> During the merge without the fixup suggested above:
>>
>> git rm -f client/client3/pom.xml
>> git checkout TopicA -- client/pom.xml
>> git mv client/pom.xml client/client3/pom.xml
>> git checkout TopicB -- client/pom.xml
>>
>> but it leaves you with an ugly history, and it would be far better to fix
>> up TopicA before the merge.
>
> Yep. I prefer a clean history ;-). So do you know how to solve that
> issue with a cleaned up TopicA branch?
I don't see an issue if you have cleaned up TopicA. Where is it? Did you
really do what you said you did?
-- Hannes
^ permalink raw reply
* Re: Push to origin failed
From: Sverre Rabbelier @ 2010-01-19 15:05 UTC (permalink / raw)
To: Johannes Schneider; +Cc: git
In-Reply-To: <4B55C48F.2090005@cedarsoft.com>
Heya,
On Tue, Jan 19, 2010 at 15:41, Johannes Schneider
<mailings@cedarsoft.com> wrote:
> ! [rejected] master -> master (non-fast forward)
There's your problem. You could solve it by instead doing 'git push
-f' (telling it to push even though it's not a fast-forward), but that
would make it hard for those downstream of that repository. So, read
up on 'fast-forwards' and why it's bad to push if it's not a
fast-forward, but mainly figure out why you have a fast-forward in the
first place. It could very well be that you need to fetch and merge
(or fetch and rebase) first.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* GIT remote server browsing without gitweb/github
From: Laszlo Papp @ 2010-01-19 15:16 UTC (permalink / raw)
To: git
Hello,
I'm sorry, Would you be so kind as to take your opinion about this
browsing problem ?
I've desribed this problem here:
http://code.google.com/p/tortoisegit/issues/detail?id=275
Thanks in advance!
Best Regards,
Laszlo Papp
^ permalink raw reply
* [PATCH] Makefile: honor NO_CURL when setting REMOTE_CURL_* variables
From: Johannes Sixt @ 2010-01-19 15:39 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Junio C Hamano, git, Johannes Sixt
Previously, these variables were set before there was a chance to set
NO_CURL.
This made a difference only during 'make install', because by installing
$(REMOTE_CURL_ALIASES), the rule tries to access $(REMOTE_CURL_PRIMARY),
which was never installed. On Windows, this fails; on Unix, stale symbolic
links are created.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Makefile | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index 8ed07cf..43fd686 100644
--- a/Makefile
+++ b/Makefile
@@ -423,18 +423,8 @@ BUILT_INS += git-show$X
BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
-ifdef NO_CURL
-REMOTE_CURL_PRIMARY =
-REMOTE_CURL_ALIASES =
-REMOTE_CURL_NAMES =
-else
-REMOTE_CURL_PRIMARY = git-remote-http$X
-REMOTE_CURL_ALIASES = git-remote-https$X git-remote-ftp$X git-remote-ftps$X
-REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
-endif
-
# what 'all' will build and 'install' will install in gitexecdir,
# excluding programs for built-in commands
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
@@ -1108,16 +1098,22 @@ ifdef NO_LIBGEN_H
endif
ifdef NO_CURL
BASIC_CFLAGS += -DNO_CURL
+ REMOTE_CURL_PRIMARY =
+ REMOTE_CURL_ALIASES =
+ REMOTE_CURL_NAMES =
else
ifdef CURLDIR
# Try "-Wl,-rpath=$(CURLDIR)/$(lib)" in such a case.
BASIC_CFLAGS += -I$(CURLDIR)/include
CURL_LIBCURL = -L$(CURLDIR)/$(lib) $(CC_LD_DYNPATH)$(CURLDIR)/$(lib) -lcurl
else
CURL_LIBCURL = -lcurl
endif
+ REMOTE_CURL_PRIMARY = git-remote-http$X
+ REMOTE_CURL_ALIASES = git-remote-https$X git-remote-ftp$X git-remote-ftps$X
+ REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
PROGRAMS += $(REMOTE_CURL_NAMES) git-http-fetch$X
curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
ifeq "$(curl_check)" "070908"
ifndef NO_EXPAT
--
1.6.6.283.g42b20a
^ permalink raw reply related
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