* Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?
From: Tomas Carnecky @ 2009-12-22 10:04 UTC (permalink / raw)
To: Git Mailing List
$ git --version
git version 1.6.6.rc4
# Documentation/perf_counter is missing from the master branch, so first
let's find
# out what the last commit was that touched that subdirectory:
$ git log --all -1 -- Documentation/perf_counter
commit 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Tue Jun 2 21:02:36 2009 +0200
...
M Documentation/perf_counter/builtin-report.c
# Great, let's look in which branch that commit is
$ git branch --contains 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
* master
# So, let's look at the log of master and limit it to that subdirectory:
$ git log master -- Documentation/perf_counter
$
# Damn, that doesn't make any sense. In commit 43622 there were files in
that subdirectory, in master they have gone missing and yet log doesn't
show any commit touching that subdirectory?
# Let's try something different:
$ git log --diff-filter=D --name-status --all -- Documentation/perf_counter
...
# Ah, now we're getting somewhere, but still no sight of a commit which
removed for example Documentation/perf_counter/.gitignore
# I'm sure I'm probably just missing a tiny little switch for git-log. I
also tried other combination of name-status, diff-filter etc, but soon
after gave up.
tom
^ permalink raw reply
* Re: Huge pack file from small unpacked objects
From: B Smith-Mannschott @ 2009-12-22 8:54 UTC (permalink / raw)
To: Nick Triantos; +Cc: git@vger.kernel.org
In-Reply-To: <75B8C0BEE0AE2A44AA971D218D9FE99E3DD8C61C@VMBX125.ihostexchange.net>
On Wed, Dec 16, 2009 at 17:34, Nick Triantos <nick@perceptivepixel.com> wrote:
> Hi,
>
> I recently created a repo from SVN via git-svn. The bare repo was about ~600MB. I cloned it, and on the clone, I added 2 small files (.gitignore and .gitattributes) to a branch, merged them to master, and pushed that back to the origin. The cloned repo remains at about 600MB, while my origin repo (the one from svn) is now about 2.4GB. I found that it created a file in objects/pack which accounts for this huge size.
>
> I've tried running 'git repack -a -d' but that didn't shrink the size of this pack file.
>
> Any ideas why the pack file is so huge? Anything I can do to shrink it? My coworkers are understandably unhappy that the repo is so huge now (makes for very slow pulls)
Have you tried "git prune"?
// Ben
^ permalink raw reply
* git fast-import not verifying commit author lines?
From: David Reiss @ 2009-12-22 4:22 UTC (permalink / raw)
To: git
mtn git_export produces this output on a simple repo:
blob
mark :1
data 8
content
commit refs/heads/com.example.badexport
mark :2
author <somename> 1261454209 +0000
committer <somename> 1261454209 +0000
data 8
acommit
M 100644 :1 "afile"
progress revision 9b0e11e4d66eba8a3cf26095fb573116b886cd37 (1/1)
#############################################################
The author and committer lines are missing the names (I've filed this as a
bug with monotone). git commit-tree refuses to to produce a commit object
like this, so it seems like git fast-import should detect and report this
instead of silently writing the invalid commit object to the repository.
--David
^ permalink raw reply
* Re: [PATCH] Prevent git blame from segfaulting on a missing author name
From: Junio C Hamano @ 2009-12-22 7:25 UTC (permalink / raw)
To: David Reiss; +Cc: git
In-Reply-To: <4B304993.2040600@facebook.com>
David Reiss <dreiss@facebook.com> writes:
> The author name should never be missing in a valid commit, but
> git shouldn't segfault no matter what is in the object database.
>
> Signed-off-by: David Reiss <dreiss@facebook.com>
> ---
> git blame was segfaulting on a repro produced by piping mtn git_export
> from the Pidgin repository to git fast-import. This was the most obvious
> fix, but I'm not sure if it is the best solution.
Thanks.
While it is _unusual_ not to have a human readable name, if the commits
come from foreign systems (e.g. CVS/SVN), there often are not sufficient
information in the source to fabricate names, so we should tolerate them.
We might want to also teach fast-import to warn when asked (i.e. when we
are feeding from a foreign interface that is designed to read from a
source that is capable of recording real names), but we shouldn't prevent
it from creating such a commit.
> Here's a script that reproduces the segfault.
Please make that into a new test in an existing test suite somewhere in t/
directory.
I think we probably should prepare ourselves to be fed with even more
broken commits, perhaps like this, if we are fixing it..
builtin-blame.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index d4e25a5..14830a3 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1305,6 +1305,7 @@ static void get_ac_line(const char *inbuf, const char *what,
error_out:
/* Ugh */
*tz = "(unknown)";
+ strcpy(person, *tz);
strcpy(mail, *tz);
*time = 0;
return;
@@ -1314,20 +1315,26 @@ static void get_ac_line(const char *inbuf, const char *what,
tmp = person;
tmp += len;
*tmp = 0;
- while (*tmp != ' ')
+ while (person < tmp && *tmp != ' ')
tmp--;
+ if (tmp == person)
+ goto error_out;
*tz = tmp+1;
tzlen = (person+len)-(tmp+1);
*tmp = 0;
- while (*tmp != ' ')
+ while (person < tmp && *tmp != ' ')
tmp--;
+ if (tmp == person)
+ goto error_out;
*time = strtoul(tmp, NULL, 10);
timepos = tmp;
*tmp = 0;
- while (*tmp != ' ')
+ while (person < tmp && *tmp != ' ')
tmp--;
+ if (tmp <= person)
+ return;
mailpos = tmp + 1;
*tmp = 0;
maillen = timepos - tmp;
^ permalink raw reply related
* [PATCH] Prevent git blame from segfaulting on a missing author name
From: David Reiss @ 2009-12-22 4:22 UTC (permalink / raw)
To: git
The author name should never be missing in a valid commit, but
git shouldn't segfault no matter what is in the object database.
Signed-off-by: David Reiss <dreiss@facebook.com>
---
git blame was segfaulting on a repro produced by piping mtn git_export
from the Pidgin repository to git fast-import. This was the most obvious
fix, but I'm not sure if it is the best solution.
Here's a script that reproduces the segfault.
#!/bin/sh
set -e
git init
echo line > afile
git add afile
TREE=`git write-tree`
cat >badcommit <<EOF
tree $TREE
author <noname> 1234567890 +0000
committer David Reiss <dreiss@facebook.com> 1234567890 +0000
some message
EOF
COMMIT=`git hash-object -t commit -w badcommit`
echo "git --no-pager blame $COMMIT -- afile"
git --no-pager blame $COMMIT -- afile
builtin-blame.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index d4e25a5..5e19c79 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1326,7 +1326,7 @@ static void get_ac_line(const char *inbuf, const char *what,
timepos = tmp;
*tmp = 0;
- while (*tmp != ' ')
+ while (tmp > person && *tmp != ' ')
tmp--;
mailpos = tmp + 1;
*tmp = 0;
--
1.6.3.3
^ permalink raw reply related
* Re: git's fascination with absolute paths
From: Junio C Hamano @ 2009-12-22 6:30 UTC (permalink / raw)
To: Avery Pennarun; +Cc: J Chapman Flack, git
In-Reply-To: <7v637z6ehg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Not really. The scripts can work with ".." just fine, as long as they
> know how to use "cd_to_topdir" and "rev-parse --show-prefix" correctly.
>
> While I do not necessarily agree with the original claim that hiding
> higher level of hierarchies are "standard" practice in UNIX (it instead
> falls into "an unusual set-up that is permitted but you have to be
> careful" category), I don't think it is fundamental that we need read
> access all the way up to the root level. It is only that getcwd(3) does.
>
> At the basic level, work tree and index operations operate relative to the root
> of the work tree. Originally, almost no privision was made to run from a
> subdirectory of a work tree (you were expected to run from the top-level,
> having ./.git as the meta information sture), and we didn't have to run
> any getcwd(3). Later we added "look at parent directories until we find
> the one that has .git subdirectory, while remembering how many levels we
> went up", in order to support operations from a subdirectory of a work
> tree. The commands chdir up to the root of the work tree and would use
> the path they climbed as a pathspec to limit the scope of their operation.
>
> While "counting how many levels we went up" can be expressed by a sequence
> of "../", turning it to the directory prefix means at some point you would
> need to do what getcwd(3) does. It wants to be able to read ".." to give
> you an absolute path.
>
> By rewriting that part of the "root-level-discovery" code to do something
> like
>
> - while test -d .git is not true:
> - stat(".") to get the inum;
> - chdir(".."); and
> - opendir(".") and readdir() to find where we were;
>
> while going up every level, you should be able to construct the prefix
> without being to able to read all the way up to the filesystem root. You
> only need to be able to read your work tree.
>
> Admittedly the code complexity got worse later when we added support for
> GIT_WORK_TREE and also GIT_CEILING_DIRECTORIES, as they fundamentally need
> to know where you are relative to the root of the filesystem tree and need
> a working getcwd(3) support, which J Chapman's set-up refuses to give.
>
> Also I wouldn't be surprised if the support for these two features cheat
> in order to reduce code complexity by always using absolute paths even in
> places where a path relative to the root of the work tree might have
> sufficed.
Clarificaiton.
The above, like many other messages from me, was not meant as a
justification, but a mere explanation of the historical fact. IOW, don't
get me wrong by interpreting that I am not interested in seeing a solution
that does not use absolute paths.
While I think the original "higher levels in the filesystems may not be
accessible" is a rather unusual set-up, making paths absolute and relying
on being able to always do so have another drawback in a not-so-unusual
setup. A work tree that is shallow (say, has only one t/ subdirectory and
short filenames) may not be usable if it is so deep in the filesystem
hierarchy that the result of getcwd(3) exceeds PATH_MAX. The "hand roll
what getcwd(3) did in traditional UNIX while looking for the root level of
the work tree" approach I outlined in the previous message will be a way
to fix such a use case; as long as the deepest level of your work tree
relative to the root of the work tree does not exceed PATH_MAX, you'll be
Ok.
We have a few known issues in the GIT_WORK_TREE (IIRC, it has a funny
interaction with alias expansion). When we reexamine the codepath that
the introduction of the feature needed to touch, I would love to see us at
least try to see if it is feasible to redo this without calling getcwd(3)
when no GIT_WORK_TREE (or core.worktree) is set.
^ permalink raw reply
* Huge pack file from small unpacked objects
From: Nick Triantos @ 2009-12-22 6:19 UTC (permalink / raw)
To: 'git@vger.kernel.org'
In-Reply-To: <404585ED79625A40AB5A9884ECA9A63B3E02083F@VMBX125.ihostexchange.net>
Hi,
(re-sending.. I'm not sure if my last send made it to the list, I got a bounce because it had HTML.)
I recently created a repo from SVN via git-svn. The bare repo was about ~600MB. I cloned it, and on the clone, I added 2 small files (.gitignore and .gitattributes) to a branch, merged them to master, and pushed that back to the origin. The cloned repo remains at about 600MB, while my origin repo (the one from svn) is now about 2.4GB. I found that it created a file in objects/pack which accounts for this huge size.
I've tried running 'git repack -a -d' but that didn't shrink the size of this pack file.
Any ideas why the pack file is so huge? Anything I can do to shrink it? My coworkers are understandably unhappy that the repo is so huge now (makes for very slow pulls)
thanks,
-Nick
^ permalink raw reply
* Re: git's fascination with absolute paths
From: Junio C Hamano @ 2009-12-22 0:26 UTC (permalink / raw)
To: Avery Pennarun; +Cc: J Chapman Flack, git
In-Reply-To: <32541b130912211409j540928c0g8e944fcc05c44f82@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> On Mon, Dec 21, 2009 at 1:42 PM, J Chapman Flack <jflack@math.purdue.edu> wrote:
>> In general it seems best for a program to stay free of assumptions
>> about absolute paths except when there is a specific functional
>> requirement that needs them. I assume there is something git does
>> that requires it to have this limitation, but it's not intuitive
>> to me if I just think about what I expect an scm system to do.
>> I've searched on 'absolute' in the list archive to see if there
>> was a past discussion like "we've decided we need absolute paths
>> everywhere because X" but I didn't find any. Can someone
>> describe what the reasoning was? A security concern perhaps?
>> (And one more serious than the race condition built into
>> make_absolute_path?)
>
> I think it's probably just because it's easier to deal with absolute
> paths than relative ones. Those ".." things can be annoying,
> particularly inside scripts, etc, and git uses a lot of scripts. Much
> more straightforward to just normalize all the paths once and be sure
> there are no weird dots in them.
Not really. The scripts can work with ".." just fine, as long as they
know how to use "cd_to_topdir" and "rev-parse --show-prefix" correctly.
While I do not necessarily agree with the original claim that hiding
higher level of hierarchies are "standard" practice in UNIX (it instead
falls into "an unusual set-up that is permitted but you have to be
careful" category), I don't think it is fundamental that we need read
access all the way up to the root level. It is only that getcwd(3) does.
At the basic work tree and index operations operate relative to the root
of the work tree. Originally, almost no privision was made to run from a
subdirectory of a work tree (you were expected to run from the top-level,
having ./.git as the meta information sture), and we didn't have to run
any getcwd(3). Later we added "look at parent directories until we find
the one that has .git subdirectory, while remembering how many levels we
went up", in order to support operations from a subdirectory of a work
tree. The commands chdir up to the root of the work tree and would use
the path they climbed as a pathspec to limit the scope of their operation.
While "counting how many levels we went up" can be expressed by a sequence
of "../", turning it to the directory prefix means at some point you would
need to do what getcwd(3) does. It wants to be able to read ".." to give
you an absolute path.
By rewriting that part of the "root-level-discovery" code to do something
like
- while test -d .git is not true:
- stat(".") to get the inum;
- chdir(".."); and
- opendir(".") and readdir() to find where we were;
while going up every level, you should be able to construct the prefix
without being to able to read all the way up to the filesystem root. You
only need to be able to read your work tree.
Admittedly the code complexity got worse later when we added support for
GIT_WORK_TREE and also GIT_CEILING_DIRECTORIES, as they fundamentally need
to know where you are relative to the root of the filesystem tree and need
a working getcwd(3) support, which J Chapman's set-up refuses to give.
Also I wouldn't be surprised if the support for these two features cheat
in order to reduce code complexity by always using absolute paths even in
places where a path relative to the root of the work tree might have
sufficed.
^ permalink raw reply
* Re: [PATCH] git-svn: Remove obsolete MAXPARENT check
From: Eric Wong @ 2009-12-21 22:39 UTC (permalink / raw)
To: Junio C Hamano, Andrew Myrick; +Cc: git, sam
In-Reply-To: <1261434174-298-1-git-send-email-amyrick@apple.com>
Andrew Myrick <amyrick@apple.com> wrote:
> Change git-svn not to impose a limit of 16 parents on a merge.
>
> This limit in git-svn artificially prevents cloning svn repositories
> that contain commits with more than 16 merge parents.
>
> The limit was removed from builtin-commit-tree.c for git v1.6.0 in commit
> ef98c5cafb3e799b1568bb843fcd45920dc62f16, so there is no need to check for it
> it in git-svn.
>
> Signed-off-by: Andrew Myrick <amyrick@apple.com>
Thanks Andrew,
Acked-by: Eric Wong <normalperson@yhbt.net>
and pushed out to git://git.bogomips.org/git-svn along with the
rest of the stuff already pushed out last night.
Andrew Myrick (1):
git-svn: Remove obsolete MAXPARENT check
Eric Wong (2):
git svn: fix --revision when fetching deleted paths
update release notes for git svn in 1.6.6
Sam Vilain (5):
git-svn: expand the svn mergeinfo test suite, highlighting some failures
git-svn: memoize conversion of SVN merge ticket info to git commit ranges
git-svn: fix some mistakes with interpreting SVN mergeinfo commit ranges
git-svn: exclude already merged tips using one rev-list call
git-svn: detect cherry-picks correctly.
--
Eric Wong
^ permalink raw reply
* [PATCH] git-svn: Remove obsolete MAXPARENT check
From: Andrew Myrick @ 2009-12-21 22:22 UTC (permalink / raw)
To: git; +Cc: sam, normalperson, Andrew Myrick
Change git-svn not to impose a limit of 16 parents on a merge.
This limit in git-svn artificially prevents cloning svn repositories
that contain commits with more than 16 merge parents.
The limit was removed from builtin-commit-tree.c for git v1.6.0 in commit
ef98c5cafb3e799b1568bb843fcd45920dc62f16, so there is no need to check for it
it in git-svn.
Signed-off-by: Andrew Myrick <amyrick@apple.com>
---
git-svn.perl | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0a6460e..92c40da 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2447,12 +2447,6 @@ sub get_commit_parents {
next if $seen{$p};
$seen{$p} = 1;
push @ret, $p;
- # MAXPARENT is defined to 16 in commit-tree.c:
- last if @ret >= 16;
- }
- if (@tmp) {
- die "r$log_entry->{revision}: No room for parents:\n\t",
- join("\n\t", @tmp), "\n";
}
@ret;
}
--
1.6.6.rc3.dirty
^ permalink raw reply related
* Re: git's fascination with absolute paths
From: Avery Pennarun @ 2009-12-21 22:09 UTC (permalink / raw)
To: J Chapman Flack; +Cc: git
In-Reply-To: <4B2FC17A.3010705@math.purdue.edu>
On Mon, Dec 21, 2009 at 1:42 PM, J Chapman Flack <jflack@math.purdue.edu> wrote:
> In general it seems best for a program to stay free of assumptions
> about absolute paths except when there is a specific functional
> requirement that needs them. I assume there is something git does
> that requires it to have this limitation, but it's not intuitive
> to me if I just think about what I expect an scm system to do.
> I've searched on 'absolute' in the list archive to see if there
> was a past discussion like "we've decided we need absolute paths
> everywhere because X" but I didn't find any. Can someone
> describe what the reasoning was? A security concern perhaps?
> (And one more serious than the race condition built into
> make_absolute_path?)
I think it's probably just because it's easier to deal with absolute
paths than relative ones. Those ".." things can be annoying,
particularly inside scripts, etc, and git uses a lot of scripts. Much
more straightforward to just normalize all the paths once and be sure
there are no weird dots in them.
Not to say that it can't be done... just that it seems nobody has been
inspired to do so. I'm guessing most of the existing developers still
won't be inspired to do it based on your rather unusual use case;
however, they might accept patches.
> Or, perhaps I should be asking, what is there in git that will
> break if I recompile it with make_absolute_path(p){return p;}?
> Does it store absolute paths in the db? Would a recompiled
> version produce a db other gits couldn't read?
You might try this and then see what happens in 'make test'. I
imagine a set of clean patches that removed a lot of assumptions about
absolute paths, without breaking any unit tests, would be something
worth considering for integration into git.
Have fun,
Avery
^ permalink raw reply
* Re: Delete a commit
From: Bertram Scharpf @ 2009-12-21 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <hgocfi$pge$1@ger.gmane.org>
Hi,
Am Montag, 21. Dez 2009, 18:49:36 +0100 schrieb Johan 't Hart:
> Bertram Scharpf schreef:
>
>> % git fsck --lost-found
>> dangling commit 6abc221327e896c850c56dafae92277bcfe68e2b
>> It is still there. This is the one I want to delete.
>
> It is not in the history of any head anymore, so you could consider it
> deleted. ('git log' does not show this commit)
>
> If you want to prune unreferenced objects, try:
> git prune
>
> ('git help prune' for options)
In the meantime I detected the gc.pruneExpire config variable. I
didn't get that to work on all versions that I have installed on
different machines, but I just wanted to understand what has to
happen with the commit.
Thank you!
Bertram
--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de
^ permalink raw reply
* [PATCH] Reword -M, when in `git log`s documention, to suggest --follow
From: Alex Vandiver @ 2009-12-21 20:40 UTC (permalink / raw)
To: git
The documentation for `git log` is sadly misleading when it comes
to tracking renames. By far the most common option that users
new to git want is the ability to view the history of a file
across renames. Unfortunately, `git log --help` shows:
NAME
git-log - Show commit logs
[...]
OPTIONS
[...]
-M
Detect renames.
...and most users stop reading there. Unfortunately, what
they're generally looking for comes significantly later:
[...]
--follow
Continue listing the history of a file beyond renames.
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
Documentation/diff-options.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 8707d0e..bcbad88 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -175,7 +175,13 @@ endif::git-format-patch[]
Break complete rewrite changes into pairs of delete and create.
-M::
+ifdef::git-log[]
+ Show renames in diff output. See `--follow` to track history
+ across renames.
+endif::git-log[]
+ifndef::git-log[]
Detect renames.
+endif::git-log[]
-C::
Detect copies as well as renames. See also `--find-copies-harder`.
--
1.6.6.rc0.363.g69d13.dirty
^ permalink raw reply related
* git's fascination with absolute paths
From: J Chapman Flack @ 2009-12-21 18:42 UTC (permalink / raw)
To: git
Hi list,
I have a requirement involving the reasonably common Unix-y design
pattern where a directory owned by a particular user lives in a
directory that user can't access, with a setuid gate that chdirs to
the right place and then drops to the real user's id to do certain
allowed things.
I wanted to use git for some of those allowed things and I can't,
because the code seems to call make_absolute_path on approximately
everything, and this is one of the situations that illustrates why it
isn't safe to assume you can get an absolute path that's even
usable (let alone race-free) corresponding to a relative path
in general.
git init tries to do this on the db path (even if
it's specified explicitly in GIT_DIR), and even if I do the git init
as root in advance, all the other git subcommands I've tried also
try to do it and fail when they chdir up out of the
working directory and try to chdir (not fchdir) back in.
In general it seems best for a program to stay free of assumptions
about absolute paths except when there is a specific functional
requirement that needs them. I assume there is something git does
that requires it to have this limitation, but it's not intuitive
to me if I just think about what I expect an scm system to do.
I've searched on 'absolute' in the list archive to see if there
was a past discussion like "we've decided we need absolute paths
everywhere because X" but I didn't find any. Can someone
describe what the reasoning was? A security concern perhaps?
(And one more serious than the race condition built into
make_absolute_path?)
Or, perhaps I should be asking, what is there in git that will
break if I recompile it with make_absolute_path(p){return p;}?
Does it store absolute paths in the db? Would a recompiled
version produce a db other gits couldn't read?
(Or less drastic perhaps, what if there were a version of m_a_p
that still returned an absolute path when possible and safe, and
just returned p otherwise so the program could still be usable?)
Thanks,
Chapman Flack
mathematics, purdue university
^ permalink raw reply
* Re: Delete a commit
From: Andreas Schwab @ 2009-12-21 18:17 UTC (permalink / raw)
To: Johan 't Hart; +Cc: git
In-Reply-To: <hgocfi$pge$1@ger.gmane.org>
Johan 't Hart <johanthart@gmail.com> writes:
> Bertram Scharpf schreef:
>> Hi,
>
>> % git fsck --lost-found
>> dangling commit 6abc221327e896c850c56dafae92277bcfe68e2b
>>
>> It is still there. This is the one I want to delete.
>
> It is not in the history of any head anymore, so you could consider it
> deleted. ('git log' does not show this commit)
Except through the reflog, most likely.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Delete a commit
From: Johan 't Hart @ 2009-12-21 17:49 UTC (permalink / raw)
To: git
In-Reply-To: <20091220004340.GA30440@marge.bs.l>
Bertram Scharpf schreef:
> Hi,
> % git fsck --lost-found
> dangling commit 6abc221327e896c850c56dafae92277bcfe68e2b
>
> It is still there. This is the one I want to delete.
It is not in the history of any head anymore, so you could consider it
deleted. ('git log' does not show this commit)
If you want to prune unreferenced objects, try:
git prune
('git help prune' for options)
> Bertram
>
>
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_HOME environment variable
From: Michael J Gruber @ 2009-12-21 16:54 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jeff King, Junio C Hamano, Miklos Vajna, Moe, git
In-Reply-To: <vpqskb49tuq.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 21.12.2009 17:26:
> Jeff King <peff@peff.net> writes:
>
>> Are we even close to having this sort of universal support for
>> ~/.config?
>
> Definitely not universal as of now. Probably precisely because each
> application thinks "I'll take care of $XDG_CONFIG_HOME after others
> do" ;-).
>
>> Traditionally, the standard for Unix
>> has been for config files to be $HOME/.something. You can argue that
>> ~/.config is a better standard, but I don't think git is failing to
>> use a standard; it is simply following a different one.
>
> I've probably been unclear about this. I'm not arguing about moving
> away from $HOME/.gitconfig as the default (IOW, we're in agreement
> here ;-) ). It's there, and the migration path would be much more
> painfull than the benefit.
>
> What I'm saying is that _if_ we introduce a variable to point to an
> alternate .gitconfig, then we should use something like
> $XDG_CONFIG_HOME/git/config and not $GIT_HOME/.gitconfig
>
> I don't have a strong opinion on whether we should introduce such
> variable (it seems the only use-case is the one which started this
> thread, and it is already solved without it, so ...).
>
>> But we do have such a variable: $HOME. The concept of $GIT_HOME was
>> proposed to provide a way to divert _just_ git to a different config
>> directory, something that would not be any easier with
>> $XDG_CONFIG_HOME.
>
> Right, but I don't see any use-case for this.
>
> The use-case which started this thread was to have several physical
> users using the same Unix account, with the desire that each physical
> user should be able to use his own editor setups. In this case, you
> want your editor and your other applications to follow the schema.
>
>> Anyway, as far as the future of git goes, even if we did want to switch
>> to $XDG_CONFIG_HOME, we could not do so suddenly without breaking
>> everybody's current setup. Which would mean any implementation of it
>> would have to handle both the current and the new proposed locations.
>> You can obviously just read from both, but there are a lot of open
>> questions, like "which should take precedence?" and "what does git
>> config --global --edit do?". I am not opposed to hearing a clever
>> proposal that handles all such issues, but I am not going to think too
>> hard about it myself. :)
>
> Right, the thing I had in mind was to use $XDG_CONFIG_HOME just like
> $GIT_HOME (i.e. use it if it's set), but doing so would suddenly break
> the setup of people having already set $XDG_CONFIG_HOME, and having a
> $HOME/.gitconfig.
>
> Well, then, I don't know, maybe my proposal wasn't as clever as I
> thought ;-).
Well, I'd say the usual approach would be "use the first one found out
of $XYZ/config and $HOME/.gitconfig in this order", whether XYZ equals
$GIT_HOME or $XDG_CONFIG_HOME/git or what not. And that applies both to
reading as well writing the config. We should only merge config from
different types of sources (system/global/local), not from alternate
locations within the same type.
That way, nobody's setup gets broken, and having "git_custom_home()"
factorized out there is no real maintenance burden. I have no opinion
about the choice of XYZ.
Michael
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_HOME environment variable
From: Matthieu Moy @ 2009-12-21 16:26 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Miklos Vajna, Moe, git
In-Reply-To: <20091221155902.GA22665@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Are we even close to having this sort of universal support for
> ~/.config?
Definitely not universal as of now. Probably precisely because each
application thinks "I'll take care of $XDG_CONFIG_HOME after others
do" ;-).
> Traditionally, the standard for Unix
> has been for config files to be $HOME/.something. You can argue that
> ~/.config is a better standard, but I don't think git is failing to
> use a standard; it is simply following a different one.
I've probably been unclear about this. I'm not arguing about moving
away from $HOME/.gitconfig as the default (IOW, we're in agreement
here ;-) ). It's there, and the migration path would be much more
painfull than the benefit.
What I'm saying is that _if_ we introduce a variable to point to an
alternate .gitconfig, then we should use something like
$XDG_CONFIG_HOME/git/config and not $GIT_HOME/.gitconfig
I don't have a strong opinion on whether we should introduce such
variable (it seems the only use-case is the one which started this
thread, and it is already solved without it, so ...).
> But we do have such a variable: $HOME. The concept of $GIT_HOME was
> proposed to provide a way to divert _just_ git to a different config
> directory, something that would not be any easier with
> $XDG_CONFIG_HOME.
Right, but I don't see any use-case for this.
The use-case which started this thread was to have several physical
users using the same Unix account, with the desire that each physical
user should be able to use his own editor setups. In this case, you
want your editor and your other applications to follow the schema.
> Anyway, as far as the future of git goes, even if we did want to switch
> to $XDG_CONFIG_HOME, we could not do so suddenly without breaking
> everybody's current setup. Which would mean any implementation of it
> would have to handle both the current and the new proposed locations.
> You can obviously just read from both, but there are a lot of open
> questions, like "which should take precedence?" and "what does git
> config --global --edit do?". I am not opposed to hearing a clever
> proposal that handles all such issues, but I am not going to think too
> hard about it myself. :)
Right, the thing I had in mind was to use $XDG_CONFIG_HOME just like
$GIT_HOME (i.e. use it if it's set), but doing so would suddenly break
the setup of people having already set $XDG_CONFIG_HOME, and having a
$HOME/.gitconfig.
Well, then, I don't know, maybe my proposal wasn't as clever as I
thought ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_HOME environment variable
From: Jeff King @ 2009-12-21 15:59 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Miklos Vajna, Moe, git
In-Reply-To: <vpqhbrkd3o6.fsf@bauges.imag.fr>
On Mon, Dec 21, 2009 at 11:25:45AM +0100, Matthieu Moy wrote:
> You may not care about consistancy between applications, but I do.
> Currently, to version-control my user's configuration, I have
> $HOME/etc containing my user's config files, and the actual config
> files are symlinks to it. If applications were agreeing on a directory
> where configuration files would be stored (is it is the case on
> systems like MS Windows, and I think Mac OS), I would just had done
> "cd this-config-directory; git init".
Are we even close to having this sort of universal support for
~/.config? I also keep my dot-files in a git repository. I don't have a
single one in ~/.config[1], but I do have ~/.profile, ~/.vimrc,
~/.netrc, ~/.gitconfig, and others[2]. Traditionally, the standard for
Unix has been for config files to be $HOME/.something. You can argue
that ~/.config is a better standard, but I don't think git is failing to
use a standard; it is simply following a different one.
[1] I'll grant that is probably because I am a curmudgeon, and spend 99%
of my computing time in xterm+bash+vim.
[2] Don't even get me started on ~/.mozilla/firefox/$RAND_HEX.default/user.js.
> With the proposed $GIT_HOME, I have a way to specify _Git_'s path to
> config files. Another application may propose $WHATEVER_ELSE_HOME, and
> yet another would say $HOME_YET_ANOTHER_ONE, and so on. There's a
> proposal to have a single environment variable for all this, why
> reject it?
But we do have such a variable: $HOME. The concept of $GIT_HOME was
proposed to provide a way to divert _just_ git to a different config
directory, something that would not be any easier with $XDG_CONFIG_HOME.
Anyway, as far as the future of git goes, even if we did want to switch
to $XDG_CONFIG_HOME, we could not do so suddenly without breaking
everybody's current setup. Which would mean any implementation of it
would have to handle both the current and the new proposed locations.
You can obviously just read from both, but there are a lot of open
questions, like "which should take precedence?" and "what does git
config --global --edit do?". I am not opposed to hearing a clever
proposal that handles all such issues, but I am not going to think too
hard about it myself. :)
-Peff
^ permalink raw reply
* Re: [RFC PATCH] Record a single transaction for conflicting push operations
From: Gustav Hållberg @ 2009-12-21 14:31 UTC (permalink / raw)
To: Karl Wiberg; +Cc: Catalin Marinas, git
In-Reply-To: <b8197bcb0912210548q67c1da4bhe023bed2811394d4@mail.gmail.com>
On 2009-12-21 14:48, Karl Wiberg wrote:
> I've seen more than one complaint that the current behavior is
> confusing even if we don't count the bug, so I thought this was part
> of the motivation.
I don't know if this would be better than the other suggested solutions,
but if "stg log" would clearly identify multi-stage entries as such, the
current confusion would probably mostly go away.
Currently this is done reasonably well for make_temp_patch(), which says
"refresh (create temporary patch)" in the log, but I think this could be
taken further.
For example, if such annotations said "foo: stage N" or similar,
indicating that this was the Nth step in the "foo" command (think
"rebase" or whatever), it would be good enough for me least.
- Gustav
^ permalink raw reply
* Re: [RFC PATCH] Record a single transaction for conflicting push operations
From: Karl Wiberg @ 2009-12-21 13:48 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Gustav Hållberg
In-Reply-To: <b0943d9e0912210348o37b71935x5fad4f1a4be4b70@mail.gmail.com>
On Mon, Dec 21, 2009 at 12:48 PM, Catalin Marinas
<catalin.marinas@gmail.com> wrote:
> 2009/12/21 Karl Wiberg <kha@treskal.com>:
>
>> By the way, you do realize there's another command that requires
>> two steps to undo completely: refresh? And that one is harder to
>> get out of---undoing it all in one step would mean throwing away
>> the updates to the patch.
>
> But it looks to me like refresh does this by running separate
> transactions.
Yes. So it won't be affected by whatever you do here. (Unless you
consider that refresh -p needs to reorder patches, which can result in
conflicts---right now, refresh -p can result in three log entries.)
> The push command does this in a single transaction, so the quickest
> fix for the HEAD != top undo problem was to only record one log per
> transaction.
I've seen more than one complaint that the current behavior is
confusing even if we don't count the bug, so I thought this was part
of the motivation.
> If we keep the current behaviour with two logs per transaction, we
> need to preserve the HEAD prior to the conflict so that logging
> doesn't get the wrong HEAD (which is the new conflicting HEAD
> currently). The patch below appears to fix this problem and still
> generate two logs per transaction. While I'm more in favour of a
> single log per transaction, if people find it useful I'm happy to
> keep the current behaviour.
I haven't seen anyone but me defent the current design, and it's not a
big deal for me either, so I'd say go with just one transaction.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC PATCH] Record a single transaction for conflicting push operations
From: Catalin Marinas @ 2009-12-21 11:48 UTC (permalink / raw)
To: Karl Wiberg; +Cc: git, Gustav Hållberg
In-Reply-To: <b8197bcb0912202308p296207av416cd5590a11251b@mail.gmail.com>
2009/12/21 Karl Wiberg <kha@treskal.com>:
> By the way, you do realize there's another command that requires two
> steps to undo completely: refresh? And that one is harder to get out
> of---undoing it all in one step would mean throwing away the updates
> to the patch.
But it looks to me like refresh does this by running separate
transactions. The push command does this in a single transaction, so
the quickest fix for the HEAD != top undo problem was to only record
one log per transaction.
If we keep the current behaviour with two logs per transaction, we
need to preserve the HEAD prior to the conflict so that logging
doesn't get the wrong HEAD (which is the new conflicting HEAD
currently). The patch below appears to fix this problem and still
generate two logs per transaction. While I'm more in favour of a
single log per transaction, if people find it useful I'm happy to keep
the current behaviour.
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index 30a153b..ba97c4f 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -197,18 +197,14 @@ class StackTransaction(object):
exception) and do nothing."""
self.__check_consistency()
log.log_external_mods(self.__stack)
- new_head = self.head
-
- # Set branch head.
- if set_head:
- if iw:
- try:
- self.__checkout(new_head.data.tree, iw, allow_bad_head)
- except git.CheckoutException:
- # We have to abort the transaction.
- self.abort(iw)
- self.__abort()
- self.__stack.set_head(new_head, self.__msg)
+
+ if set_head and iw:
+ try:
+ self.__checkout(self.head.data.tree, iw, allow_bad_head)
+ except git.CheckoutException:
+ # We have to abort the transaction.
+ self.abort(iw)
+ self.__abort()
if self.__error:
if self.__conflicts:
@@ -216,8 +212,11 @@ class StackTransaction(object):
else:
out.error(self.__error)
- # Write patches.
- def write(msg):
+ # Write patches and update the branch head.
+ def write(msg, new_head):
+ # Set branch head.
+ if new_head:
+ self.__stack.set_head(new_head, self.__msg)
for pn, commit in self.__patches.iteritems():
if self.__stack.patches.exists(pn):
p = self.__stack.patches.get(pn)
@@ -231,12 +230,16 @@ class StackTransaction(object):
self.__stack.patchorder.unapplied = self.__unapplied
self.__stack.patchorder.hidden = self.__hidden
log.log_entry(self.__stack, msg)
+
old_applied = self.__stack.patchorder.applied
- write(self.__msg)
if self.__conflicting_push != None:
+ write(self.__msg, set_head and self.head)
self.__patches = _TransPatchMap(self.__stack)
self.__conflicting_push()
- write(self.__msg + ' (CONFLICT)')
+ write(self.__msg + ' (CONFLICT)', set_head and self.head)
+ else:
+ write(self.__msg, set_head and self.head)
+
if print_current_patch:
_print_current_patch(old_applied, self.__applied)
@@ -346,10 +349,10 @@ class StackTransaction(object):
if merge_conflict:
# When we produce a conflict, we'll run the update()
# function defined below _after_ having done the
- # checkout in run(). To make sure that we check out
- # the real stack top (as it will look after update()
- # has been run), set it hard here.
- self.head = comm
+ # checkout in run(). Make sure that we have a consistent
+ # HEAD before the update function is called below (which
+ # sets the real HEAD).
+ self.head = self.top
else:
comm = None
s = 'unmodified'
@@ -367,6 +370,8 @@ class StackTransaction(object):
x = self.unapplied
del x[x.index(pn)]
self.applied.append(pn)
+ # Set the real conflicting HEAD.
+ self.head = comm
if merge_conflict:
# We've just caused conflicts, so we must allow them in
# the final checkout.
diff --git a/t/t3103-undo-hard.sh b/t/t3103-undo-hard.sh
index 2d0f382..a71cd32 100755
--- a/t/t3103-undo-hard.sh
+++ b/t/t3103-undo-hard.sh
@@ -46,7 +46,7 @@ test_expect_success 'Try to undo without --hard' '
cat > expected.txt <<EOF
EOF
-test_expect_failure 'Try to undo with --hard' '
+test_expect_success 'Try to undo with --hard' '
stg undo --hard &&
stg status a > actual.txt &&
test_cmp expected.txt actual.txt &&
--
Catalin
^ permalink raw reply related
* Re: [PATCH 2/5] git-svn: memoize conversion of SVN merge ticket info to git commit ranges
From: Eric Wong @ 2009-12-21 10:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andrew Myrick, Sam Vilain
In-Reply-To: <1261344246.20752.24.camel@denix>
Sam Vilain <sam@vilain.net> wrote:
> On Sun, 2009-12-20 at 05:33 +1300, Sam Vilain wrote:
> > +sub lookup_svn_merge {
> > + my $uuid = shift;
> > + my $url = shift;
> > + my $merge = shift;
> > +
> > + my ($source, $revs) = split ":", $merge;
> > + my $path = $source;
> > + $path =~ s{^/}{};
> > + my $gs = Git::SVN->find_by_url($url.$source, $url, $path);
> > + if ( !$gs ) {
> > + warn "Couldn't find revmap for $url$source\n";
> > + next;
> > + }
>
> As mentioned in the other thread, that 'next' should now be 'return'.
Thanks Sam and Andrew. I've acked this series and pushed them out along
with a release notes update as well as another small fix (inline below).
Eric Wong (2):
git svn: fix --revision when fetching deleted paths
update release notes for git svn in 1.6.6
Sam Vilain (5):
git-svn: expand the svn mergeinfo test suite, highlighting some failures
git-svn: memoize conversion of SVN merge ticket info to git commit ranges
git-svn: fix some mistakes with interpreting SVN mergeinfo commit ranges
git-svn: exclude already merged tips using one rev-list call
git-svn: detect cherry-picks correctly.
>From 577e9fcad2c8968846b365226b89778050496a78 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Mon, 21 Dec 2009 02:06:04 -0800
Subject: [PATCH] git svn: fix --revision when fetching deleted paths
When using the -r/--revision argument to fetch deleted history,
calling SVN::Ra::get_log() from an SVN::Ra object initialized
to track the deleted URL will fail.
This regression was introduced in:
commit 4aacaeb3dc82bb6479e70e120053dc27a399460e
"fix shallow clone when upstream revision is too new"
We now ignore errors from SVN::Ra::get_log() here because using
--revision will always override the value of $head here if
(and only if) we're tracking deleted directories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d362de7..a6f5061 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1741,7 +1741,11 @@ sub fetch_all {
my $ra = Git::SVN::Ra->new($url);
my $uuid = $ra->get_uuid;
my $head = $ra->get_latest_revnum;
- $ra->get_log("", $head, 0, 1, 0, 1, sub { $head = $_[1] });
+
+ # ignore errors, $head revision may not even exist anymore
+ eval { $ra->get_log("", $head, 0, 1, 0, 1, sub { $head = $_[1] }) };
+ warn "W: $@\n" if $@;
+
my $base = defined $fetch ? $head : 0;
# read the max revs for wildcard expansion (branches/*, tags/*)
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] Introduce the GIT_HOME environment variable
From: Matthieu Moy @ 2009-12-21 10:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Moe, git
In-Reply-To: <7vskb6bwvu.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
>>
>> It solves the same problem ("set on environment variable, and change
>> my whole Git config"), but
>>
>> * It's a standard. It's really nice to be able to ...
>> * It avoids hidden files. With $GIT_CONFIG, a user doing
>
> I think the above are actually three bullet points (i.e. you lack line
> break and bullet before "It's really nice").
No, I don't.
You can do
| cd ~/.config
| ls
|
| to see a user's configuration for many applications at a time,
_because_ it's a standard, and because it's followed by several
applications.
> And the third bullet is more or less a small subset of the second
> one, since you need "ls -a" without making them non-dot,
The standard may not write black-on-white
$XDG_CONFIG_HOME/subdir/filename _with filename being non-hidden_, but
in practice, this is what's happening.
> And I personally don't care very much about that second "It's really
> nice to be able to" point.
You may not care about consistancy between applications, but I do.
Currently, to version-control my user's configuration, I have
$HOME/etc containing my user's config files, and the actual config
files are symlinks to it. If applications were agreeing on a directory
where configuration files would be stored (is it is the case on
systems like MS Windows, and I think Mac OS), I would just had done
"cd this-config-directory; git init".
With the proposed $GIT_HOME, I have a way to specify _Git_'s path to
config files. Another application may propose $WHATEVER_ELSE_HOME, and
yet another would say $HOME_YET_ANOTHER_ONE, and so on. There's a
proposal to have a single environment variable for all this, why
reject it?
> As to the particular "standard" cited, I don't know how relevant it is to
> us at this moment, or in this topic. Judging from the fact that it
> doesn't even define the scope of the standard (e.g. what classes of
> applications are expected to follow it, for what benefit do they follow
> it, how are they expected to handle differences between their historical
> practice and the new world order it introduces, etc. etc....), I suspect
> it is a very early draft that will be heavily copyedited before final,
> once professional standard writers start looking at it.
I mostly agree on the critics, but do you have any better "standard"
(actually, not necessarily an official standard, but "something that
various applications can agree on") to propose?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: possible code error at run_command.c
From: Frank Li @ 2009-12-21 9:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: kusmabite, git
In-Reply-To: <4B2F3732.6030903@viscovery.net>
> This line will trigger the check. It initializes failed_errno with itself,
> which is still uninitialized at this time.
>
I see.
I always use release version at finial production.
This is not important. I read code again. There are not path.
Thank you take care.
^ 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