* Re: [PATCH] Do _not_ call unlink on a directory
From: Linus Torvalds @ 2007-07-17 19:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Glanzmann, git
In-Reply-To: <7vtzs3a0xg.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Jul 2007, Junio C Hamano wrote:
>
> This is wrong. If the filesystem has a symlink and we would
> want a directory there, we should unlink(). So at least the
> stat there needs to be lstat().
Good catch. Ack.
Linus
^ permalink raw reply
* Re: Installation failure caused by CDPATH environment variable
From: Junio C Hamano @ 2007-07-17 18:37 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Wincent Colaiuta, git
In-Reply-To: <20070717114024.GA12215@informatik.uni-freiburg.de>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> writes:
> Junio C Hamano wrote:
>> We could write it as "$(TAR) Ccf blt - ." if we can rely on the
>> 'C' option, but I suspect it is a GNU extension. Does anybody
>> have POSIX.1 handy?
> I don't have POSIX.1 handy, but on Solaris 10, you need to say:
>
> tar cf - -C blt .
>
> (That is, Solaris' tar has the 'C' option, which is quite a good
> indication, that it's included in POSIX :-)
Oh, I cannot resist ;-)
Solaris has unlink(2) capable of removing a directory, but I do
not think it is included in POSIX.
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Junio C Hamano @ 2007-07-17 18:34 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20070717101527.GB7774@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <thomas@glanzmann.de> writes:
>> I wonder if anybody involved in the discussion has actually
>> tested this patch (or the other one, that has the same problem)?
>
> I tested it. But I did not test it with symlinks.
>
>> Does the following replacement work for you? It adds far more lines
>> than your version, but they are mostly comments to make it clear why
>> we do things this way.
>
> Yes, it does. Excuse the delay but my build machine is not the fastest.
>
> (faui04a) [/var/tmp] git clone ~/work/repositories/public/easix.git test-10
> Initialized empty Git repository in /var/tmp/test-10/.git/
> remote: Generating pack...
> remote: Done counting 317 objects.
> remote: Deltifying 317 objects...
> remote: te: % (317/317) done: ) done
> Indexing 317 objects...
> remote: Total 317 (delta 182), reused 278 (delta 157)
> 100% (317/317) done
> Resolving 182 deltas...
> 100% (182/182) done
> (faui04a) [/var/tmp] cd test-10
> ./test-10
> (faui04a) [/var/tmp/test-10] git status
> # On branch master
> nothing to commit (working directory clean)
Ahhhh, by "testing", I meant "runnnig the testsuite shipped with
the source". Both of your patches were failing in somewhere in
t2000 series of tests.
> I rebased your patch on top of current HEAD (as I can access it on
> git.kernel.org) and removed trailing whitspace from one line (git-apply
> complained)
I am thinking that this fix should go to 'maint' and merged to
'master', as it is a grave problem in at least one setup.
^ permalink raw reply
* [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Sven Verdoolaege @ 2007-07-17 18:28 UTC (permalink / raw)
To: Junio C Hamano, git
In particular, when moving back to a commit without a given submodule
and then moving back forward to a commit with the given submodule,
we shouldn't complain that updating would lose untracked file in
the submodule, because git currently does not checkout subprojects
during superproject check-out.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
I'm not sure if t7400-submodule-basic is the best place
for the test, but it has the right context for the test.
skimo
t/t7400-submodule-basic.sh | 9 +++++
unpack-trees.c | 75 +++++++++++++++++++++++++++++--------------
2 files changed, 59 insertions(+), 25 deletions(-)
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5e91db6..e8ce7cd 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -21,6 +21,10 @@ subcommands of git-submodule.
# -add an entry to .gitmodules for submodule 'example'
#
test_expect_success 'Prepare submodule testing' '
+ : > t &&
+ git-add t &&
+ git-commit -m "initial commit" &&
+ git branch initial HEAD &&
mkdir lib &&
cd lib &&
git init &&
@@ -166,4 +170,9 @@ test_expect_success 'status should be "up-to-date" after update' '
git-submodule status | grep "^ $rev1"
'
+test_expect_success 'checkout superproject with subproject already present' '
+ git-checkout initial &&
+ git-checkout master
+'
+
test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index 89dd279..7cc029e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -5,6 +5,7 @@
#include "cache-tree.h"
#include "unpack-trees.h"
#include "progress.h"
+#include "refs.h"
#define DBRT_DEBUG 1
@@ -425,11 +426,24 @@ static void invalidate_ce_path(struct cache_entry *ce)
cache_tree_invalidate_path(active_cache_tree, ce->name);
}
-static int verify_clean_subdirectory(const char *path, const char *action,
+/*
+ * Check that checking out ce->sha1 in subdir ce->name is not
+ * going to overwrite any working files.
+ *
+ * Currently, git does not checkout subprojects during a superproject
+ * checkout, so it is not going to overwrite anything.
+ */
+static int verify_clean_submodule(struct cache_entry *ce, const char *action,
+ struct unpack_trees_options *o)
+{
+ return 0;
+}
+
+static int verify_clean_subdirectory(struct cache_entry *ce, const char *action,
struct unpack_trees_options *o)
{
/*
- * we are about to extract "path"; we would not want to lose
+ * we are about to extract "ce->name"; we would not want to lose
* anything in the existing directory there.
*/
int namelen;
@@ -437,13 +451,24 @@ static int verify_clean_subdirectory(const char *path, const char *action,
struct dir_struct d;
char *pathbuf;
int cnt = 0;
+ unsigned char sha1[20];
+
+ if (S_ISGITLINK(ntohl(ce->ce_mode)) &&
+ resolve_gitlink_ref(ce->name, "HEAD", sha1) == 0) {
+ /* If we are not going to update the submodule, then
+ * we don't care.
+ */
+ if (!hashcmp(sha1, ce->sha1))
+ return 0;
+ return verify_clean_submodule(ce, action, o);
+ }
/*
* First let's make sure we do not have a local modification
* in that directory.
*/
- namelen = strlen(path);
- pos = cache_name_pos(path, namelen);
+ namelen = strlen(ce->name);
+ pos = cache_name_pos(ce->name, namelen);
if (0 <= pos)
return cnt; /* we have it as nondirectory */
pos = -pos - 1;
@@ -451,7 +476,7 @@ static int verify_clean_subdirectory(const char *path, const char *action,
struct cache_entry *ce = active_cache[i];
int len = ce_namelen(ce);
if (len < namelen ||
- strncmp(path, ce->name, namelen) ||
+ strncmp(ce->name, ce->name, namelen) ||
ce->name[namelen] != '/')
break;
/*
@@ -469,16 +494,16 @@ static int verify_clean_subdirectory(const char *path, const char *action,
* present file that is not ignored.
*/
pathbuf = xmalloc(namelen + 2);
- memcpy(pathbuf, path, namelen);
+ memcpy(pathbuf, ce->name, namelen);
strcpy(pathbuf+namelen, "/");
memset(&d, 0, sizeof(d));
if (o->dir)
d.exclude_per_dir = o->dir->exclude_per_dir;
- i = read_directory(&d, path, pathbuf, namelen+1, NULL);
+ i = read_directory(&d, ce->name, pathbuf, namelen+1, NULL);
if (i)
die("Updating '%s' would lose untracked files in it",
- path);
+ ce->name);
free(pathbuf);
return cnt;
}
@@ -487,7 +512,7 @@ static int verify_clean_subdirectory(const char *path, const char *action,
* We do not want to remove or overwrite a working tree file that
* is not tracked, unless it is ignored.
*/
-static void verify_absent(const char *path, const char *action,
+static void verify_absent(struct cache_entry *ce, const char *action,
struct unpack_trees_options *o)
{
struct stat st;
@@ -495,15 +520,15 @@ static void verify_absent(const char *path, const char *action,
if (o->index_only || o->reset || !o->update)
return;
- if (has_symlink_leading_path(path, NULL))
+ if (has_symlink_leading_path(ce->name, NULL))
return;
- if (!lstat(path, &st)) {
+ if (!lstat(ce->name, &st)) {
int cnt;
- if (o->dir && excluded(o->dir, path))
+ if (o->dir && excluded(o->dir, ce->name))
/*
- * path is explicitly excluded, so it is Ok to
+ * ce->name is explicitly excluded, so it is Ok to
* overwrite it.
*/
return;
@@ -515,7 +540,7 @@ static void verify_absent(const char *path, const char *action,
* files that are in "foo/" we would lose
* it.
*/
- cnt = verify_clean_subdirectory(path, action, o);
+ cnt = verify_clean_subdirectory(ce, action, o);
/*
* If this removed entries from the index,
@@ -543,7 +568,7 @@ static void verify_absent(const char *path, const char *action,
* delete this path, which is in a subdirectory that
* is being replaced with a blob.
*/
- cnt = cache_name_pos(path, strlen(path));
+ cnt = cache_name_pos(ce->name, strlen(ce->name));
if (0 <= cnt) {
struct cache_entry *ce = active_cache[cnt];
if (!ce_stage(ce) && !ce->ce_mode)
@@ -551,7 +576,7 @@ static void verify_absent(const char *path, const char *action,
}
die("Untracked working tree file '%s' "
- "would be %s by merge.", path, action);
+ "would be %s by merge.", ce->name, action);
}
}
@@ -575,7 +600,7 @@ static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
}
}
else {
- verify_absent(merge->name, "overwritten", o);
+ verify_absent(merge, "overwritten", o);
invalidate_ce_path(merge);
}
@@ -590,7 +615,7 @@ static int deleted_entry(struct cache_entry *ce, struct cache_entry *old,
if (old)
verify_uptodate(old, o);
else
- verify_absent(ce->name, "removed", o);
+ verify_absent(ce, "removed", o);
ce->ce_mode = 0;
add_cache_entry(ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
invalidate_ce_path(ce);
@@ -707,18 +732,18 @@ int threeway_merge(struct cache_entry **stages,
if (o->aggressive) {
int head_deleted = !head && !df_conflict_head;
int remote_deleted = !remote && !df_conflict_remote;
- const char *path = NULL;
+ struct cache_entry *ce = NULL;
if (index)
- path = index->name;
+ ce = index;
else if (head)
- path = head->name;
+ ce = head;
else if (remote)
- path = remote->name;
+ ce = remote;
else {
for (i = 1; i < o->head_idx; i++) {
if (stages[i] && stages[i] != o->df_conflict_entry) {
- path = stages[i]->name;
+ ce = stages[i];
break;
}
}
@@ -733,8 +758,8 @@ int threeway_merge(struct cache_entry **stages,
(remote_deleted && head && head_match)) {
if (index)
return deleted_entry(index, index, o);
- else if (path && !head_deleted)
- verify_absent(path, "removed", o);
+ else if (ce && !head_deleted)
+ verify_absent(ce, "removed", o);
return 0;
}
/*
--
1.5.3.rc2.10.g148b
^ permalink raw reply related
* Re: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
From: Matt McCutchen @ 2007-07-17 18:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis, Luben Tuikov
In-Reply-To: <200707121307.03612.jnareb@gmail.com>
On 7/12/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > The advantage of '| gzip' is that the lack of a compressor is
> > not a special case. This is why I wrote %known_snapshot_formats the
> > way I did, but of course you all are welcome to overrule me.
>
> I wrote about this because I'm thinking about replacing the few
> pipelines we use in gitweb[*1*], including the snapshot one, with
> the list form, which has the advantage of avoiding spawning the shell
> (performance) and not dealing with shell quoting of arguments (security
> and errors), like we did for simple calling of git commands to read
> from in the commit b9182987a80f7e820cbe1f8c7c4dc26f8586e8cd
> "gitweb: Use list for of open for running git commands, thorougly"
>
> Thus I'd rather have list of extra commands and arguments instead of
> pipe as a string, i.e. 'gzip' instead of '| gzip', and 'gzip', '-9'
> instead of '| gzip -9'.
>
> [*1*] We currently use pipelines for snapshots which need external
> compressor, like tgz and tbz2, and for pickaxe search.
OK, I changed the extra commands to list form. The field is now a
reference to the compressor argv like ['gzip'] or undef if there is no
compressor.
> I also prefer the second option, perhaps as simple as 'gzip' => 'tbz'
> and 'bzip2' => 'tbz2', and of course accompaning code to deal with this.
>
> As to "display name" column: I'm not sure if for example 'tar.gz'
> instead of 'tgz' would be not easier to understand.
I went ahead and added both aliases and display names (currently
'tar.gz', 'tar.bz2', and 'zip'). Aliases are resolved in
&feature_snapshot for repository configuration but not for side-wide
configuration because then aliases in side-wide configuration would be
resolved only if override is on, which would be weird. For the same
reason, I changed the filtering out of unknown formats in
&feature_snapshot to apply only to repository configuration.
> > It would be possible to make the gitweb site configuration
> > backward-compatible too; here's one possible approach. On startup,
> > gitweb would check whether $feature{'snapshot'}{'default'} is a
> > three-element list that appears to be in the old format. If so, it
> > would save the settings in $known_snapshot_formats{'default'} and then
> > set $feature{'snapshot'}{'default'} = 'default' . This is a hack; is
> > it justified by the compatibility benefit?
>
> If you implement 'gzip' and 'bzip2' as aliases, it could be as simple
> as just taking last non-false element of array if the array has more
> than one element.
No, because it must be possible for the site default to consist of
multiple formats. It would be possible to take all elements that are
recognized as snapshot formats and ignore the others, but I would like
to be able to distinguish between "formats" that are part of a legacy
specification and completely bogus formats so that we can issue a
warning or error for the latter.
> But I'm not sure if it is worth it.
At this point I am leaning against backward compatibility for the site
configuration, and if I do implement it, I would just recognize the
three exact specifications that currently appear in feature_snapshot.
Recognizing other legacy specifications is iffy in the first place,
and handling them would require the hack I described.
I will send the revised patch soon.
Matt
^ permalink raw reply
* Do a better job at guessing unknown character sets
From: Linus Torvalds @ 2007-07-17 17:34 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
At least in the kernel development community, we're generally slowly
converting to UTF-8 everywhere, and the old default of Latin1 in emails is
being supplanted by UTF-8, and it doesn't necessarily show up as such in
the mail headers (because, quite frankly, when people send patches
around, they want the email client to do as little as humanly possible
about the patch)
Despite that, it's often the case that email addresses etc still have
Latin1, so I've seen emails where this is a mixed bag, with Signed-off
parts being copied from email (and containing Latin1 characters), and the
rest of the email being a patch in UTF-8.
So this suggests a very natural change: if the target character set is
utf-8 (the default), and if the source already looks like utf-8, just
assume that it doesn't need any conversion at all.
Only assume that it needs conversion if it isn't already valid utf-8, in
which case we (for historical reasons) will assume it's Latin1.
Basically no really _valid_ latin1 will ever look like utf-8, so while
this changes our historical behaviour, it doesn't do so in practice, and
makes the default behaviour saner for the case where the input was already
in proper format.
We could do a more fancy guess, of course, but this correctly handled a
series of patches I just got from Andrew that had a mixture of Latin1 and
UTF-8 (in different emails, but without any character set indication).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
I think this makes sense from a "the world is moving to utf-8" standpoint,
even if obviously some people might consider it a bit ugly to do per-line
"guessing".
Comments?
builtin-mailinfo.c | 33 +++++++++++++++++++++++++++++----
1 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 489c2c5..a37a4ff 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -499,15 +499,40 @@ static int decode_b_segment(char *in, char *ot, char *ep)
return 0;
}
+/*
+ * When there is no known charset, guess.
+ *
+ * Right now we assume that if the target is UTF-8 (the default),
+ * and it already looks like UTF-8 (which includes US-ASCII as its
+ * subset, of course) then that is what it is and there is nothing
+ * to do.
+ *
+ * Otherwise, we default to assuming it is Latin1 for historical
+ * reasons.
+ */
+static const char *guess_charset(const char *line, const char *target_charset)
+{
+ if (is_encoding_utf8(target_charset)) {
+ if (is_utf8(line))
+ return NULL;
+ }
+ return "latin1";
+}
+
static void convert_to_utf8(char *line, const char *charset)
{
- static const char latin_one[] = "latin1";
- const char *input_charset = *charset ? charset : latin_one;
- char *out = reencode_string(line, metainfo_charset, input_charset);
+ char *out;
+
+ if (!charset || !*charset) {
+ charset = guess_charset(line, metainfo_charset);
+ if (!charset)
+ return;
+ }
+ out = reencode_string(line, metainfo_charset, charset);
if (!out)
die("cannot convert from %s to %s\n",
- input_charset, metainfo_charset);
+ charset, metainfo_charset);
strcpy(line, out);
free(out);
}
^ permalink raw reply related
* [PATCH] git-svn: Minimalistic patch which allows svn usernames with space(s).
From: Richard MUSIL @ 2007-07-17 17:02 UTC (permalink / raw)
To: git
Changed filter for username in svn-authors file, so even 'user name' is accepted.
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 01c3904..975075e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -740,7 +740,7 @@ sub load_authors {
my $log = $cmd eq 'log';
while (<$authors>) {
chomp;
- next unless /^(\S+?|\(no author\))\s*=\s*(.+?)\s*<(.+)>\s*$/;
+ next unless /^(\.+?|\(no author\))\s*=\s*(.+?)\s*<(.+)>\s*$/;
my ($user, $name, $email) = ($1, $2, $3);
if ($log) {
$Git::SVN::Log::rusers{"$name <$email>"} = $user;
--
1.5.1.6
^ permalink raw reply related
* Re: git bisect not accepting -git kernels
From: Amit Walambe @ 2007-07-17 17:15 UTC (permalink / raw)
To: GIT; +Cc: Amit Walambe (awalambe@arcom.com)
In-Reply-To: <Pine.LNX.4.64.0707171809190.29062@reaper.quantumfyre.co.uk>
Julian Phillips wrote:
> On Tue, 17 Jul 2007, Amit Walambe wrote:
>
>> But telling good/bad points to git bisect still fails, whether I pass
>> the commit-id or the tags I created with commands given by René :
>>
>> root@amit:/usr/src/linux-git # git bisect good
>> 8f41958bdd577731f7411c9605cfaa9db6766809
>> cat: .git/BISECT_NAMES: No such file or directory
>> root@amit:/usr/src/linux-git #
>> root@amit:/usr/src/linux-git #
>> root@amit:/usr/src/linux-git # git tag v2.6.22-git6
>> 8f41958bdd577731f7411c9605cfaa9db6766809
>> root@amit:/usr/src/linux-git # git tag v2.6.22-git8
>> a5fcaa210626a79465321e344c91a6a7dc3881fa
>> root@amit:/usr/src/linux-git #
>> root@amit:/usr/src/linux-git #
>> root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
>> cat: .git/BISECT_NAMES: No such file or directory
>> root@amit:/usr/src/linux-git #
>> root@amit:/usr/src/linux-git #
>> root@amit:/usr/src/linux-git #
>> root@amit:/usr/src/linux-git # git bisect bad v2.6.22-git8
>> cat: .git/BISECT_NAMES: No such file or directory
>>
>> Thanks and Regards,
>>
>
> you seem to be missing a "git bisect start" from that sequence ... see
> the man page for more details.
Yes indeed. Somehow the state was messed up due to different commands I
had tried. Now it works ok.
root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
root@amit:/usr/src/linux-git # git bisect bad v2.6.22-git8
Bisecting: 362 revisions left to test after this
[02b2318e07f98a7cdf7089a4457a8d62424aa824] Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
Thanks a lot for everyone for their help. _Much appreciated_!
Best Regards,
--
Amit Walambe
Design Engineer, Arcom Control Systems Ltd.
http://www.arcom.com
Tel: +44-(0)1223 411200 ext. 3204
Direct: +44-(0)1223 403465
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been virus scanned by MessageLabs.
^ permalink raw reply
* [PATCH 2/2] Add tests for cherry-pick d/f conflict which should be none
From: Johannes Schindelin @ 2007-07-17 17:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git, Rémi Vanicat
In-Reply-To: <7v8x9q1x5t.fsf@assigned-by-dhcp.cox.net>
This tests that we fixed the problem when a directory was renamed,
and a symlink was added in its place (or for that matter, if
the type changed in one branch, and the name in another).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
The last test checks that also a file/symlink conflict does
not break cherry-pick, if one side had a clean rename.
t/t3502-cherry-pick.sh | 43 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 43 insertions(+), 0 deletions(-)
create mode 100755 t/t3502-cherry-pick.sh
diff --git a/t/t3502-cherry-pick.sh b/t/t3502-cherry-pick.sh
new file mode 100755
index 0000000..9921de5
--- /dev/null
+++ b/t/t3502-cherry-pick.sh
@@ -0,0 +1,43 @@
+#!/bin/sh
+
+test_description='test cherry-pick'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo foo > file &&
+ ln -s dangling link &&
+ git add file link &&
+ test_tick &&
+ git commit -m foo &&
+ git checkout -b branch &&
+ git rm link &&
+ test_tick &&
+ git commit -m "remove link" &&
+ mkdir link &&
+ echo bar > link/file &&
+ git add link/file &&
+ test_tick &&
+ git commit -m "add dir" &&
+ echo bar > file &&
+ git commit -m "change file" file &&
+ git checkout master
+'
+
+test_expect_success 'cherry-pick ignores unrelated dir/symlink conflict' '
+ git cherry-pick branch
+'
+
+test_expect_success 'cherry-pick ignores unrelated file/symlink conflict' '
+ git checkout -b branch2 master^ &&
+ git rm link &&
+ test_tick &&
+ git commit -m "remove link" &&
+ : > link &&
+ git add link &&
+ test_tick &&
+ git commit -m "add file" &&
+ git cherry-pick master
+'
+
+test_done
--
1.5.3.rc1.16.g9d6f-dirty
^ permalink raw reply related
* Re: git bisect not accepting -git kernels
From: Rogan Dawes @ 2007-07-17 17:11 UTC (permalink / raw)
To: Amit Walambe; +Cc: git
In-Reply-To: <469CF52D.10407@arcom.com>
Amit Walambe wrote:
> Thanks a ton everyone for all the replies.
> Here is the current status :
>
> René Scharfe wrote:
>> Amit Walambe schrieb:
>>> Hi!
>>> I was trying to do a git bisect on 2.6.22-git6 and 2.6.22-git8. For
>>> which I get following error :
>>> root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
>>> Bad rev input: v2.6.22-git6
>>
>> The -git snapshots are made automatically by kernel.org, and their name
>> is not included in the git repository. You could create tags for them
>> like this:
>>
>> git tag v2.6.22-git6 8f41958bdd577731f7411c9605cfaa9db6766809
>> git tag v2.6.22-git8 a5fcaa210626a79465321e344c91a6a7dc3881fa
>>
>> ... and afterwards you can use those revision names with bisect (or
>> other git commands). I've got the commit IDs (i.e. those mysterious 40
>> hex digits above) from the first line of the changelogs; their URLs are:
>>
>> http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git6.log
>> http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git8.log
> I found the commit ids in following file as well :
> http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git6.id
> http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git8.id
>
> But telling good/bad points to git bisect still fails, whether I pass
> the commit-id or the tags I created with commands given by René :
>
> root@amit:/usr/src/linux-git # git bisect good
> 8f41958bdd577731f7411c9605cfaa9db6766809
> cat: .git/BISECT_NAMES: No such file or directory
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git # git tag v2.6.22-git6
> 8f41958bdd577731f7411c9605cfaa9db6766809
> root@amit:/usr/src/linux-git # git tag v2.6.22-git8
> a5fcaa210626a79465321e344c91a6a7dc3881fa
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
> cat: .git/BISECT_NAMES: No such file or directory
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git # git bisect bad v2.6.22-git8
> cat: .git/BISECT_NAMES: No such file or directory
>
> Thanks and Regards,
You need to start off by saying
$ git bisect start
to set up the necessary infrastructure.
Rogan
^ permalink raw reply
* [PATCH 1/2] merge-recursive: sometimes, d/f conflict is not an issue
From: Johannes Schindelin @ 2007-07-17 17:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git, Rémi Vanicat
In-Reply-To: <7v8x9q1x5t.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3697 bytes --]
When a merge has a d/f conflict on a path which was not touched
between the merge base(s) and the remote HEAD, and the index and
HEAD contain the same version for that path (even if empty), it
is not really a conflict.
Noticed by Rémi Vanicat, reported to the Git list by Gerrit Pape.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Turns out I was wrong with my "this is only half of it" remark.
AFAICT "merge-tree -u -m" does not touch the files which have
unmerged entries, but merge-recursive does. And since
fix_up_df_conflicts() is called before any of that, it just works.
merge-recursive.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index c8539ec..fb487ba 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -243,6 +243,91 @@ static int git_merge_trees(int index_only,
return rc;
}
+/*
+ * If there were dir/file conflicts, which are not really dir/file
+ * conflicts, because only one side changed anything, take that
+ * side instead of outputting silly conflicts.
+ *
+ * We keep it nice and easy, in that we only fix the conflicts if one
+ * side was renamed without changing the contents _at all_. We check that
+ * by comparing the hash.
+ */
+static inline int is_df(struct cache_entry *in_dir, struct cache_entry *file)
+{
+ int len = ce_namelen(file);
+ const char *name = in_dir->name;
+ return !memcmp(name, file->name, len) && name[len] == '/';
+}
+
+static int fix_up_df_conflicts(const unsigned char *base,
+ const unsigned char *head, const unsigned char *merge)
+{
+ int i;
+ for (i = 0; i + 2 < active_nr; i++) {
+ int last;
+ unsigned char sha1[20], sha2[20];
+ unsigned dummy;
+ char *name;
+ struct cache_entry *ce = active_cache[i], *ce1, *ce2;
+
+ if (ce_stage(ce) == 0)
+ continue;
+ ce1 = active_cache[i + 1];
+ ce2 = active_cache[i + 2];
+ if (ce_same_name(ce, ce2) || !is_df(ce2, ce)) {
+ /* not a d/f conflict */
+ i += 2;
+ continue;
+ }
+ for (last = i + 3; last < active_nr &&
+ is_df(active_cache[last], ce); last++)
+ ; /* do nothing */
+ /* check if unchanged in HEAD */
+ if (ce_same_name(ce, ce1)) {
+ if (ce_stage(ce) != 1 ||
+ hashcmp(ce->sha1, ce1->sha1)) {
+ /* file was changed */
+ i = last - 1;
+ continue;
+ }
+ /* other side removed file, added dir */
+ if (!remove_file_from_cache(ce->name))
+ return error("index error");
+ for (i -= 2, last -= 2; i < last; i++)
+ active_cache[i]->ce_flags &=
+ ~ntohs(CE_STAGEMASK);
+ i--;
+ continue;
+ }
+ if (i + 1 == last)
+ continue;
+ /* check if HEAD changed type (e.g. dir->file) */
+ if (ce_stage(ce) == 1) {
+ i = last - 1;
+ continue;
+ }
+ name = xstrndup(ce->name, ce_namelen(ce));
+ if (get_tree_entry(base, name, sha1, &dummy) ||
+ get_tree_entry(ce_stage(ce) == 2 ?
+ merge : head,
+ name, sha2, &dummy)) {
+ free(name);
+ i = last - 1;
+ continue;
+ }
+ free(name);
+ if (!hashcmp(sha1, sha2)) {
+ /* remove tree */
+ memmove(active_cache + i + 1, active_cache + last,
+ (active_nr - last) *
+ sizeof(struct cache_entry *));
+ active_nr -= last - i - 1;
+ ce->ce_flags &= ~ntohs(CE_STAGEMASK);
+ }
+ }
+ return 0;
+}
+
static int unmerged_index(void)
{
int i;
@@ -1542,6 +1627,8 @@ static int merge_trees(struct tree *head,
sha1_to_hex(head->object.sha1),
sha1_to_hex(merge->object.sha1));
+ fix_up_df_conflicts(common->object.sha1,
+ head->object.sha1, merge->object.sha1);
if (unmerged_index()) {
struct path_list *entries, *re_head, *re_merge;
int i;
--
1.5.3.rc1.16.g9d6f-dirty
^ permalink raw reply related
* Re: git bisect not accepting -git kernels
From: Julian Phillips @ 2007-07-17 17:10 UTC (permalink / raw)
To: Amit Walambe; +Cc: git
In-Reply-To: <469CF52D.10407@arcom.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1282 bytes --]
On Tue, 17 Jul 2007, Amit Walambe wrote:
> But telling good/bad points to git bisect still fails, whether I pass the
> commit-id or the tags I created with commands given by René :
>
> root@amit:/usr/src/linux-git # git bisect good
> 8f41958bdd577731f7411c9605cfaa9db6766809
> cat: .git/BISECT_NAMES: No such file or directory
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git # git tag v2.6.22-git6
> 8f41958bdd577731f7411c9605cfaa9db6766809
> root@amit:/usr/src/linux-git # git tag v2.6.22-git8
> a5fcaa210626a79465321e344c91a6a7dc3881fa
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
> cat: .git/BISECT_NAMES: No such file or directory
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git #
> root@amit:/usr/src/linux-git # git bisect bad v2.6.22-git8
> cat: .git/BISECT_NAMES: No such file or directory
>
> Thanks and Regards,
>
you seem to be missing a "git bisect start" from that sequence ... see the
man page for more details.
--
Julian
---
Peter Griffin: You wanna talk about awkward moments? Once, during sex, I called Lois "Frank". Your move, Sherlock.
^ permalink raw reply
* Re: git bisect not accepting -git kernels
From: Amit Walambe @ 2007-07-17 17:06 UTC (permalink / raw)
To: GIT; +Cc: Amit Walambe (awalambe@arcom.com)
In-Reply-To: <469CF00C.4040906@arcom.com>
Amit Walambe wrote:
> I didn't build my own git version. What I did do was to remove the old
> git and ensure I am using the Debian installed one.
>
> Now I am getting a different error :
> root@amit:/usr/src/linux-git # which git
> /usr/bin/git
> root@amit:/usr/src/linux-git # git --version
> git version 1.5.2.3
> root@amit:/usr/src/linux-git # git bisect good v2.6.22-rc6
> root@amit:/usr/src/linux-git # git bisect bad v2.6.22-rc8
> fatal: Needed a single revision
> root@amit:/usr/src/linux-git #
I should call it a day. Above commands are wrong. I need to work on -git
kernels and not -rc kernels (as the above commands are showing).
I am still getting the same errors I started with :
root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
Bad rev input: v2.6.22-git6
root@amit:/usr/src/linux-git #
root@amit:/usr/src/linux-git #
root@amit:/usr/src/linux-git # git bisect good v2.6.22-git8
Bad rev input: v2.6.22-git8
> A quick search on the net didn't yield anything. Please help me find out
> what's going wrong.
> Thanks and Regards,
The above greatly applies :)
--
Amit Walambe
Design Engineer, Arcom Control Systems Ltd.
http://www.arcom.com
Tel: +44-(0)1223 411200 ext. 3204
Direct: +44-(0)1223 403465
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been virus scanned by MessageLabs.
^ permalink raw reply
* Re: git bisect not accepting -git kernels
From: Amit Walambe @ 2007-07-17 16:58 UTC (permalink / raw)
To: git; +Cc: Amit Walambe (awalambe@arcom.com)
In-Reply-To: <469CF2E6.1020104@lsrfire.ath.cx>
Thanks a ton everyone for all the replies.
Here is the current status :
René Scharfe wrote:
> Amit Walambe schrieb:
>> Hi!
>> I was trying to do a git bisect on 2.6.22-git6 and 2.6.22-git8. For
>> which I get following error :
>> root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
>> Bad rev input: v2.6.22-git6
>
> The -git snapshots are made automatically by kernel.org, and their name
> is not included in the git repository. You could create tags for them
> like this:
>
> git tag v2.6.22-git6 8f41958bdd577731f7411c9605cfaa9db6766809
> git tag v2.6.22-git8 a5fcaa210626a79465321e344c91a6a7dc3881fa
>
> ... and afterwards you can use those revision names with bisect (or
> other git commands). I've got the commit IDs (i.e. those mysterious 40
> hex digits above) from the first line of the changelogs; their URLs are:
>
> http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git6.log
> http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git8.log
I found the commit ids in following file as well :
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git6.id
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git8.id
But telling good/bad points to git bisect still fails, whether I pass
the commit-id or the tags I created with commands given by René :
root@amit:/usr/src/linux-git # git bisect good
8f41958bdd577731f7411c9605cfaa9db6766809
cat: .git/BISECT_NAMES: No such file or directory
root@amit:/usr/src/linux-git #
root@amit:/usr/src/linux-git #
root@amit:/usr/src/linux-git # git tag v2.6.22-git6
8f41958bdd577731f7411c9605cfaa9db6766809
root@amit:/usr/src/linux-git # git tag v2.6.22-git8
a5fcaa210626a79465321e344c91a6a7dc3881fa
root@amit:/usr/src/linux-git #
root@amit:/usr/src/linux-git #
root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
cat: .git/BISECT_NAMES: No such file or directory
root@amit:/usr/src/linux-git #
root@amit:/usr/src/linux-git #
root@amit:/usr/src/linux-git #
root@amit:/usr/src/linux-git # git bisect bad v2.6.22-git8
cat: .git/BISECT_NAMES: No such file or directory
Thanks and Regards,
--
Amit Walambe
Design Engineer, Arcom Control Systems Ltd.
http://www.arcom.com
Tel: +44-(0)1223 411200 ext. 3204
Direct: +44-(0)1223 403465
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been virus scanned by MessageLabs.
^ permalink raw reply
* Re: git bisect not accepting -git kernels
From: René Scharfe @ 2007-07-17 16:48 UTC (permalink / raw)
To: Amit Walambe; +Cc: git
In-Reply-To: <469CE836.6010508@arcom.com>
Amit Walambe schrieb:
> Hi!
> I was trying to do a git bisect on 2.6.22-git6 and 2.6.22-git8. For
> which I get following error :
> root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
> Bad rev input: v2.6.22-git6
>
> The repository is obtained by :
> root@amit:/usr/src # git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 linux-git
>
> I am running following git version on Debian Sid, updated today.
> # git --version
> git version 0.99.8.GIT
> '# dpkg -l | grep git' shows ' git-core 1:1.5.2.3-1'
>
> I tried searching man-pages/documentation/website but couldn't find any
> references to git bisect on -git kernels. I would be grateful if anyone
> can help me find what's going wrong.
The -git snapshots are made automatically by kernel.org, and their name
is not included in the git repository. You could create tags for them
like this:
git tag v2.6.22-git6 8f41958bdd577731f7411c9605cfaa9db6766809
git tag v2.6.22-git8 a5fcaa210626a79465321e344c91a6a7dc3881fa
... and afterwards you can use those revision names with bisect (or
other git commands). I've got the commit IDs (i.e. those mysterious 40
hex digits above) from the first line of the changelogs; their URLs are:
http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git6.log
http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22-git8.log
René
^ permalink raw reply
* Re: git bisect not accepting -git kernels
From: Sam Ravnborg @ 2007-07-17 16:44 UTC (permalink / raw)
To: Amit Walambe; +Cc: git
In-Reply-To: <469CE836.6010508@arcom.com>
On Tue, Jul 17, 2007 at 05:03:02PM +0100, Amit Walambe wrote:
> Hi!
> I was trying to do a git bisect on 2.6.22-git6 and 2.6.22-git8. For
> which I get following error :
> root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
> Bad rev input: v2.6.22-git6
>
> The repository is obtained by :
> root@amit:/usr/src # git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 linux-git
The -git# is added by a script and does not exists as tags.
The same place where you retreive the -git files has a file identifying
the commit that is the latest - use the SHA of this and you should
be happy.
Sam
^ permalink raw reply
* Re: git bisect not accepting -git kernels
From: Amit Walambe @ 2007-07-17 16:36 UTC (permalink / raw)
To: GIT; +Cc: Amit Walambe (awalambe@arcom.com)
In-Reply-To: <20070717161607.GD16209@cip.informatik.uni-erlangen.de>
Hi,
Thanks for both the replies.
Thomas Glanzmann wrote:
> Hello,
>
>> # git --version
>> git version 0.99.8.GIT
>
> this doesn't match
>
>> '# dpkg -l | grep git' shows ' git-core 1:1.5.2.3-1'
This struck me as being weird, but I thought 'git' utility version is
different than the package. My mistake! :)
> that. Maybe you should build your own git packages. Lucky you that it is
> pretty easy with debian. Have a look at this thread:
I didn't build my own git version. What I did do was to remove the old
git and ensure I am using the Debian installed one.
Now I am getting a different error :
root@amit:/usr/src/linux-git # which git
/usr/bin/git
root@amit:/usr/src/linux-git # git --version
git version 1.5.2.3
root@amit:/usr/src/linux-git # git bisect good v2.6.22-rc6
root@amit:/usr/src/linux-git # git bisect bad v2.6.22-rc8
fatal: Needed a single revision
root@amit:/usr/src/linux-git #
A quick search on the net didn't yield anything. Please help me find out
what's going wrong.
Thanks and Regards,
--
Amit Walambe
Design Engineer, Arcom Control Systems Ltd.
http://www.arcom.com
Tel: +44-(0)1223 411200 ext. 3204
Direct: +44-(0)1223 403465
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been virus scanned by MessageLabs.
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-17 16:36 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
In-Reply-To: <200707170849.35842.andyparkins@gmail.com>
On 7/17/07, Andy Parkins <andyparkins@gmail.com> wrote:
>
> Does this really give a speedup?
>
> I'd be surprised, as long as the parse is being done during the output from
> git using the QProcess::readyRead() signal once and only once, then git is
> the bottle neck. Parsing the stream is almost trivial in comparison to the
> work that git is doing.
>
Well, it's not exactly from readyRead() but you are right, the bottle
neck it's git.
A bare:
time git log --parents --boundary --pretty=raw -z --log-size
--topo-order HEAD > /dev/null
gives on linux and git repositories
git 960ms
linux 6920ms
Instead qgit gives, with the same command:
WITHOUT --log-size patch
git 1170ms (+21%)
linux 7942ms (+15%)
WITH --log-size patch
git 1125ms (+17%)
linux 7820ms (+13%)
I don't know why overhead on Linux is less, probably on small repos
the GUI part of qgit that you can consider more or less a constant
time weights more regarding parsing.
Marco
^ permalink raw reply
* Re: Seeing differences at origin/branch?
From: J. Bruce Fields @ 2007-07-17 16:23 UTC (permalink / raw)
To: Thomas Adam; +Cc: git
In-Reply-To: <18071eea0707170853r41962edfge603ccec7b2e72cb@mail.gmail.com>
On Tue, Jul 17, 2007 at 04:53:03PM +0100, Thomas Adam wrote:
> This is perhaps going to seem like a very CVS/SVN type of question,
> but is there a way to see a list of differences between one's local
> copy and the origin branch? I'm after something analogous to "svn
> status -u" really (yes, I know I could get my hands scorched for such
> things. :P). Is this possible?
>
> I've tried:
>
> git-diff-tree -p origin/master
>
> But that won't list changes waiting for me that I would get when I
> issue a "git pull".
After first doing a "git fetch", to update your local view of those
remote branches:
Commits on your current branch, not in origin:
git diff origin..HEAD
Commits in the origin branch, not in your current branch (so this is
what you'd probably get if you pulled):
git diff HEAD..origin
Commits in either one, not in the other (the union of the above two):
git diff HEAD...origin
The "HEAD" is actually optional in all the above.
And, finally, I think
gitk HEAD...origin
gives the clearest picture of what's actually going on.
--b.
^ permalink raw reply
* Re: git bisect not accepting -git kernels
From: Thomas Glanzmann @ 2007-07-17 16:16 UTC (permalink / raw)
To: Amit Walambe; +Cc: GIT
In-Reply-To: <469CE836.6010508@arcom.com>
Hello,
> # git --version
> git version 0.99.8.GIT
this doesn't match
> '# dpkg -l | grep git' shows ' git-core 1:1.5.2.3-1'
that. Maybe you should build your own git packages. Lucky you that it is
pretty easy with debian. Have a look at this thread:
http://groups.google.com/group/linux.kernel/browse_thread/thread/b8509269407c0fdc/d05d0547e7dfcf03?lnk=st&q=author%3AThomas+author%3AGlanzmann+git+linux.kernel&rnum=1#d05d0547e7dfcf03
especially the first post (scroll up).
Thomas
^ permalink raw reply
* 'git gc' & number of unpacked objects ?
From: Yakov Lerner @ 2007-07-17 16:14 UTC (permalink / raw)
To: Git Mailing List
By the analogy with the maxtime and maxmount in the ext3 when it
reminds you to fsck, when number of mounts since last fsck, or time since
last fsck is above some limits. I think this makes practical sense. I think
the similar thing makes sense wrt to 'git gc'.
Is it possible that git repo had a parameter N, and when the counter of
unpacked object hit this number, then git operations start to print
semi-annoying warnings
"Time to optimize your repo using 'git gc' command ... "
?
I am naive user. I forget things. Really. I rely on git to remember things.
Is this a reasonable parameter ?
Thanks
Yakov
^ permalink raw reply
* Re: git bisect not accepting -git kernels
From: Peter Baumann @ 2007-07-17 16:13 UTC (permalink / raw)
To: Amit Walambe; +Cc: git
In-Reply-To: <469CE836.6010508@arcom.com>
On Tue, Jul 17, 2007 at 05:03:02PM +0100, Amit Walambe wrote:
> Hi!
> I was trying to do a git bisect on 2.6.22-git6 and 2.6.22-git8. For which I
> get following error :
> root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
> Bad rev input: v2.6.22-git6
>
> The repository is obtained by :
> root@amit:/usr/src # git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 linux-git
>
> I am running following git version on Debian Sid, updated today.
> # git --version
> git version 0.99.8.GIT
There is a very old GIT version in your PATH (version 0.99*), which
takes preference over the version from sid.
> '# dpkg -l | grep git' shows ' git-core 1:1.5.2.3-1'
>
-Peter
^ permalink raw reply
* Re: Seeing differences at origin/branch?
From: Brian Downing @ 2007-07-17 16:12 UTC (permalink / raw)
To: Thomas Adam; +Cc: git
In-Reply-To: <18071eea0707170853r41962edfge603ccec7b2e72cb@mail.gmail.com>
On Tue, Jul 17, 2007 at 04:53:03PM +0100, Thomas Adam wrote:
> This is perhaps going to seem like a very CVS/SVN type of question,
> but is there a way to see a list of differences between one's local
> copy and the origin branch? I'm after something analogous to "svn
> status -u" really (yes, I know I could get my hands scorched for such
> things. :P). Is this possible?
>
> I've tried:
>
> git-diff-tree -p origin/master
>
> But that won't list changes waiting for me that I would get when I
> issue a "git pull".
Use "git fetch" to fetch the remote changes, but not merge them into
your local tracked branches. "git pull" basically just does "git fetch"
then "git merge" into your current branch if it is tracking a remote
branch.
You might as well use "git diff" as well, as "git-diff-tree" is
definitely plumbing.
% git fetch origin
...
% git diff origin/master
-bcd
^ permalink raw reply
* Re: git-config: replaces ~/.gitconfig symlink with real file
From: Johannes Schindelin @ 2007-07-17 16:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Bradford Smith, git
In-Reply-To: <tnx4pk39mju.fsf@arm.com>
Hi,
On Tue, 17 Jul 2007, Catalin Marinas wrote:
> "Bradford Smith" <bradford.carl.smith@gmail.com> wrote:
> > However, when I tried running 'git-config --global color.diff auto'
> > today, it removed my symlink and replaced it with a real file. This
> > left me briefly a bit confused when the changes I had made didn't show
> > up in ~/etc/gitconfig, but git-config reported them anyway.
>
> Another problem I have with 'git config --global' is that it changes
> the access permission bits of ~/.gitconfig. Since I use the same file
> to store global StGIT configuration like SMTP username and password,
> I'd like to make its access 0600 but it always goes back to 0644 after
> 'git config --global'.
>
> Maybe fixing the symlink case would solve my problem as well.
More likely not. The way to solve it would be to follow the link if the
target path is one. As such, the _file_ would be rewritten.
So your problem is unrelated, and would need a separate fix.
Ciao,
Dscho
^ permalink raw reply
* git bisect not accepting -git kernels
From: Amit Walambe @ 2007-07-17 16:03 UTC (permalink / raw)
To: git; +Cc: Amit Walambe (awalambe@arcom.com)
Hi!
I was trying to do a git bisect on 2.6.22-git6 and 2.6.22-git8. For
which I get following error :
root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6
Bad rev input: v2.6.22-git6
The repository is obtained by :
root@amit:/usr/src # git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 linux-git
I am running following git version on Debian Sid, updated today.
# git --version
git version 0.99.8.GIT
'# dpkg -l | grep git' shows ' git-core
1:1.5.2.3-1'
I tried searching man-pages/documentation/website but couldn't find any
references to git bisect on -git kernels. I would be grateful if anyone
can help me find what's going wrong.
As I am not subscribed to the mailing-list, please cc me to all the
messages on the thread.
Thanks and Regards,
--
Amit Walambe
Design Engineer, Arcom Control Systems Ltd.
http://www.arcom.com
Tel: +44-(0)1223 411200 ext. 3204
Direct: +44-(0)1223 403465
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been virus scanned by MessageLabs.
^ 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