* Re: [PATCH 1/2] unpack-trees: handle lstat failure for existing directory
From: Miles Bader @ 2011-01-13 4:37 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, gitster, Nguyễn Thái Ngọc Duy,
Clemens Buchacher, Alex Riesen
In-Reply-To: <20110113022636.GB8635@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> @@ -1382,7 +1382,9 @@ static int verify_absent_1(struct cache_entry *ce,
> return check_ok_to_remove(ce->name, ce_namelen(ce),
> ce_to_dtype(ce), ce, &st,
> error_type, o);
> -
> + if (errno != ENOENT)
> + return error("cannot stat '%s': %s", ce->name,
> + strerror(errno));
> return 0;
Is errno guaranteed to be set to something relevant at this point in the
code...?
-miels
--
Religion, n. A daughter of Hope and Fear, explaining to Ignorance the nature
of the Unknowable.
^ permalink raw reply
* Re: Forcing re-reading files with unchanged stats
From: Jeff King @ 2011-01-13 3:32 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Maaartin, git
In-Reply-To: <4D2E6D99.9060907@dbservice.com>
On Thu, Jan 13, 2011 at 04:12:25AM +0100, Tomas Carnecky wrote:
> On 1/12/11 3:07 PM, Maaartin wrote:
> >There are files in my working tree which changes, but their size and mtime
> >remains the same (I know it's strange, but it's useful). Can I make git to re-
>
> When can this be useful?
>
> >read them all, so it recognizes the change? Ideally, using a configuration
> >variable. The repo is fairly small, so speed is no issue here.
>
> Try git update-index --refresh. I'm not aware of any config option,
> but you might want to look through man git-config.
That won't work, as it respects the stat information. So does
--really-refresh. AFAIK, there isn't a way to tell update-index to
ignore start information, short of blowing away the index entirely, and
doing a read-tree to repopulate it.
I'm curious what this use case is, and whether it would be acceptable to
update something like ctime on the files to make them stat-dirty to git.
-Peff
^ permalink raw reply
* Re: working with a large repository and git svn
From: Jonathan Nieder @ 2011-01-13 3:23 UTC (permalink / raw)
To: Wesley J. Landaker; +Cc: Joe Corneli, git, Ramkumar Ramachandra
In-Reply-To: <201101120830.47016.wjl@icecavern.net>
Wesley J. Landaker wrote:
> 3) I love git-svn for working with Subversion repositories, but you could
> consider a different tool, like tailor, if you can't make git-svn do what
> you want. I have also heard talk (but I don't know the state of things) of
> people working on a fast-import tool for SVN, so you could git-fast-export
> and svn-fast-import in a big batch.
I think the state of the art is currently git2svn[1] + "svnrdump load".
This requires permission to change properties on the svn repo, just
like svnsync would.
Hope that helps,
Jonathan
[1] http://repo.or.cz/w/git2svn.git
^ permalink raw reply
* Re: Forcing re-reading files with unchanged stats
From: Tomas Carnecky @ 2011-01-13 3:12 UTC (permalink / raw)
To: Maaartin; +Cc: git
In-Reply-To: <loom.20110112T150313-103@post.gmane.org>
On 1/12/11 3:07 PM, Maaartin wrote:
> There are files in my working tree which changes, but their size and mtime
> remains the same (I know it's strange, but it's useful). Can I make git to re-
When can this be useful?
> read them all, so it recognizes the change? Ideally, using a configuration
> variable. The repo is fairly small, so speed is no issue here.
Try git update-index --refresh. I'm not aware of any config option, but
you might want to look through man git-config.
tom
^ permalink raw reply
* [PATCH 2/2] unpack-trees: handle lstat failure for existing file
From: Jonathan Nieder @ 2011-01-13 2:28 UTC (permalink / raw)
To: git
Cc: gitster, Nguyễn Thái Ngọc Duy, Clemens Buchacher,
Alex Riesen
In-Reply-To: <20110113022415.GA8635@burratino>
When check_leading_path notices a file in the way of a new entry to be
checked out, verify_absent uses (1) the mode to determine whether it
is a directory (2) the rest of the stat information to check if this
is actually an old entry, disguised by a change in filename (e.g.,
README -> Readme) that is significant to git but insignificant to the
underlying filesystem. If lstat fails, these checks are performed
with an uninitialied stat structure, producing essentially random
results.
Better to just error out when lstat fails.
The easiest way to reproduce this is to remove a file after the
check_leading_path call and before the lstat in verify_absent. An
lstat failure other than ENOENT in check_leading_path would also
trigger the same code path.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
unpack-trees.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index a795db5..9c3fe64 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1374,7 +1374,9 @@ static int verify_absent_1(struct cache_entry *ce,
char path[PATH_MAX + 1];
memcpy(path, ce->name, len);
path[len] = 0;
- lstat(path, &st);
+ if (lstat(path, &st))
+ return error("cannot stat '%s': %s", path,
+ strerror(errno));
return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
error_type, o);
--
1.7.4.rc1
^ permalink raw reply related
* [PATCH 1/2] unpack-trees: handle lstat failure for existing directory
From: Jonathan Nieder @ 2011-01-13 2:26 UTC (permalink / raw)
To: git
Cc: gitster, Nguyễn Thái Ngọc Duy, Clemens Buchacher,
Alex Riesen
In-Reply-To: <20110113022415.GA8635@burratino>
When check_leading_path notices no file in the way of the new entry to
be checked out, verify_absent checks whether there is a directory
there or nothing at all. If that lstat call fails (for example due to
ENOMEM), it assumes ENOENT, meaning a directory with untracked files
would be clobbered in that case.
Check errno after calling lstat, and for conditions other than ENOENT,
just error out.
This is a theoretical race condition. lstat has to succeed moments
before it fails for there to be trouble.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Does this need an o->gently check?
unpack-trees.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 1ca41b1..a795db5 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1382,7 +1382,9 @@ static int verify_absent_1(struct cache_entry *ce,
return check_ok_to_remove(ce->name, ce_namelen(ce),
ce_to_dtype(ce), ce, &st,
error_type, o);
-
+ if (errno != ENOENT)
+ return error("cannot stat '%s': %s", ce->name,
+ strerror(errno));
return 0;
}
--
1.7.4.rc1
^ permalink raw reply related
* [RFC/PATCH 0/2] unpack-trees: handle lstat failures in verify_absent
From: Jonathan Nieder @ 2011-01-13 2:24 UTC (permalink / raw)
To: git
Cc: gitster, Nguyễn Thái Ngọc Duy, Clemens Buchacher,
Alex Riesen
In-Reply-To: <1230843273-11056-2-git-send-email-drizzd@aon.at>
Here are two cases where we ignore the result from lstat in
unpack_trees. I think we rather shouldn't ignore it. Sane?
Jonathan Nieder (2):
unpack-trees: handle lstat failure for existing directory
unpack-trees: handle lstat failure for existing file
unpack-trees.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: working with a large repository and git svn
From: Joe Corneli @ 2011-01-13 0:54 UTC (permalink / raw)
Cc: git
In-Reply-To: <201101120830.47016.wjl@icecavern.net>
> 1) Sounds like git-svn is running out of resources on your machine --
> that's probably a bug, but work around it: Don't dcommit all 20000 revisions
> at once. Maybe write a shell script that goes through and dcommits a 100
> commits at a time.
Hm, I found a related blog post here, but designed for interactive use:
http://fredericiana.com/2009/12/31/partial-svn-dcommit-with-git/
Could you give me a more detailed hint about how to do what you suggested?
> 2) Do you need the full history to be in SVN? Can you rebase/squash large
> parts together and thus need to commit less revisions in the first place?
Maybe. We want a tool for managing the entire history, and Git seems
like a good tool for that. At the same time, checking out the entire
history can take a long time - if we could just check out just the
latest files and check them back in in a sensible way, that would be
good - SVN does seem suitable for that purpose. If there's a git-only
way to do this I'd be happy to know about that as well!
> 3) I love git-svn for working with Subversion repositories, but you could
> consider a different tool, like tailor, if you can't make git-svn do what
> you want.
Tried it, but it didn't even get through the initiation phase. I
asked for help in the relevant mailing list.
> people working on a fast-import tool for SVN, so you could git-fast-export
> and svn-fast-import in a big batch.
Not finding these.
> 4) Does 8 GB of data really belong in the same repository? Maybe it should
> really be split up and used with git submodules or SVN externals? That may
> make things easier to work with in the long term.
Probably true. if there was a nice way to give each *file* its own
associated "repository", then stitch these together into packets (even
"on demand"), that would be cool. I was assuming we could do fancy
stuff like this as "future work" however - and it would seem that if
we use a completely git-based solution we'll be there.
> 5) Do you really want to be going from Git, to Subversion? That seems like
> a big step backwards. =)
If there's a good way to just pull down the latest revision into a
working copy and be able to push that back to the repo that would be
nice. This doesn't seem to be the Git way, but for an 8 gig repo it's
probably pretty important feature. Thoughts?
Thanks,
Joe
^ permalink raw reply
* Re: HTTP push not respecting .netrc
From: David Borowitz @ 2011-01-13 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, git
In-Reply-To: <7vy66p1vn3.fsf@alter.siamese.dyndns.org>
On Wed, Jan 12, 2011 at 16:42, Junio C Hamano <gitster@pobox.com> wrote:
> Has this been resolved to satisfaction? Just being curious...
I went on vacation, came back, and it magically worked (or maybe I
typed something else); you know how these things can be. I'll
definitely use those tips and respond on this thread if it happens
again.
^ permalink raw reply
* Re: HTTP push not respecting .netrc
From: Junio C Hamano @ 2011-01-13 0:42 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: David Borowitz, git
In-Reply-To: <AANLkTi=4cE711TtqE0E-05s9Pk72C8OymNf_-5NhrfXS@mail.gmail.com>
Has this been resolved to satisfaction? Just being curious...
^ permalink raw reply
* Re: [RFC/PATCH] Documentation: start to explain what git replace is for
From: Maaartin @ 2011-01-12 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <20110112000812.GA31950@burratino>
Jonathan Nieder <jrnieder <at> gmail.com> writes:
> +. The following example comes from ??????? ??????:
I know unicode exists already for many years, but in cygwin I get just a bunch
of question marks instead of the name. So I'd suggest to replace "Алексей
Шумкин" by "Alexej Shumkin" or whatever his preferred transcription is.
> +<1> Find all parentless commits in the 'master' branch;
> +for 'master' read the branch holding v2.5 history.
Aren't you later calling it "FIRST" and assuming there's only one?
> +$ sed -i "/^tree / a \\
> +parent $(git rev-parse v2.4)" <tmp >new <4>
Isn't the combination of "-i" (=in-place edit) with redirection wrong? I hardly
know anything about sed (abandoned it in favor of perl many years ago).
> +$ git hash-object -t commit -w new <5>
> +$ git replace FIRST <object id from hash-object> <6>
I'd prefer something like
+$ objectId=$(git hash-object -t commit -w new)
+$ git replace FIRST $objectId
This is easier for people just willing to use it without much thinking, and
also for those having no idea that git-hash-object creates a new object.
That said, it's a nice example and I've learned quite a few things.
^ permalink raw reply
* Re: [PATCH v2] commit: suggest --amend --reset-author to fix commiter identity
From: Jeff King @ 2011-01-12 18:39 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <1294856954-26841-1-git-send-email-Matthieu.Moy@imag.fr>
On Wed, Jan 12, 2011 at 07:29:14PM +0100, Matthieu Moy wrote:
> Since the message advise to fix the configuration first, the advantage
> of this command is that it is cut-and-paste ready, while using
> --author='...' requires the user to type his name and email a second
> time.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> Sorry, I did a resend the other day, which was plain wrong (I had the
> changes in my tree, but sent before commit--amend-ing).
>
> This one should be OK.
Yeah, this one looks good.
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: I want to report a bug/anomaly in Git
From: Jeff King @ 2011-01-12 18:35 UTC (permalink / raw)
To: Tony Sales; +Cc: git
In-Reply-To: <AANLkTimt+U3oo4FaywUr86ArG8d29yWAeVYhpRkBYa_K@mail.gmail.com>
On Tue, Jan 11, 2011 at 10:22:29PM +0000, Tony Sales wrote:
> The bug is that if you happen to create a new remote branch which
> shares it's name with an existing directory in the top level of the
> git repository, git then seems to get confused and the: git checkout
> <branch> - command doesn't switch to that branch or turn tracking on
> (and seems to think it was created from origin/<branch> rather than
> from refs/remotes/origin/<branch>), which it does if the branch
> doesn't share a name with an existing top level directory. This can be
> rectified by running: git checkout --track -b debian origin/debian
I don't think this is a bug so much as a confusing application of too
much DWIMmery in git-checkout. "git checkout foo" can mean several
things:
1. If it's a branch name, then switch to that branch.
2. Otherwise, if it's a tag name, switch to a detached HEAD at that
tag.
3. Otherwise, if it's a file known to git, then checkout its content
in the index into the working tree.
4. Otherwise, if there is a remote branch that matches
refs/remotes/*/foo, create a new branch "foo" that tracks it.
So the problem is that you expect behavior (4), but behavior (3) is
getting in the way.
I assume it was written this way because (4) came much later, and
therefore came last so as not to break existing behavior for the other
cases. Conceptually, though, I think it makes more sense for it to come
(3) (i.e., to keep all of the "checking out a ref" behavior together).
And one can disambiguate the path-mode already by doing:
git checkout -- debian
-Peff
^ permalink raw reply
* [PATCH v2] commit: suggest --amend --reset-author to fix commiter identity
From: Matthieu Moy @ 2011-01-12 18:29 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1294754860-17701-1-git-send-email-Matthieu.Moy@imag.fr>
Since the message advise to fix the configuration first, the advantage
of this command is that it is cut-and-paste ready, while using
--author='...' requires the user to type his name and email a second
time.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Sorry, I did a resend the other day, which was plain wrong (I had the
changes in my tree, but sent before commit--amend-ing).
This one should be OK.
builtin/commit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 22ba54f..03cff5a 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -45,9 +45,9 @@ static const char implicit_ident_advice[] =
" git config --global user.name \"Your Name\"\n"
" git config --global user.email you@example.com\n"
"\n"
-"If the identity used for this commit is wrong, you can fix it with:\n"
+"After doing this, you may fix the identity used for this commit with:\n"
"\n"
-" git commit --amend --author='Your Name <you@example.com>'\n";
+" git commit --amend --reset-author\n";
static const char empty_amend_advice[] =
"You asked to amend the most recent commit, but doing so would make\n"
--
1.7.4.rc0.2.g3e22c.dirty
^ permalink raw reply related
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Jeff King @ 2011-01-12 18:21 UTC (permalink / raw)
To: JT Olds; +Cc: git
In-Reply-To: <AANLkTinMX0yEPvSc-c=96R42SbFZTjW5Mnveuxk3ZHS=@mail.gmail.com>
On Wed, Jan 12, 2011 at 09:15:41AM -0700, JT Olds wrote:
> On every fresh install of Ubuntu that I have used (by default, I use
> ecryptfs for my home directory, which of course has its own set of
> silly Git errors right now), when I clone from a remote repository,
> have changes local to me, and changes on the remote repository, do
> 'git pull --rebase', occasionally my GIT_AUTHOR_NAME gets set to my
> GIT_AUTHOR_EMAIL on my changes that get applied on top of the remote
> changes.
Weird. I have never heard of anything like it.
Some things off the top of my head: Does your GIT_AUTHOR_NAME or
GIT_AUTHOR_EMAIL contain any odd characters that might confuse a parser?
Do you do anything special with setting up those environment variables
in your shell (e.g., in a .bashrc or .profile; those files _shouldn't_
be read by a non-interactive shell, but it's something to investigate)?
For that matter, how do you set up your identity in general (by
environment, or in ~/.gitconfig, or a local .git/config in each repo),
and what does it contain?
Can you try running this in a repo that's giving you problems:
. git-sh-setup
git log --format=%H --author=your.name |
while read rev; do
get_author_ident_from_commit $rev
git format-patch -1 --stdout $rev |
git mailinfo /dev/null /dev/null
done | less
and check that the output looks sane? I want to make sure there's
nothing in your commits that is confusing our parser.
If that doesn't turn up anything, I think the next thing to try would be
making a script that reproduces the problem for you, and see if I can
reproduce it here.
-Peff
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Uwe Kleine-König @ 2011-01-12 18:19 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110112174600.GB31747@sigill.intra.peff.net>
Hi,
On Wed, Jan 12, 2011 at 12:46:00PM -0500, Jeff King wrote:
> On Wed, Jan 12, 2011 at 10:11:30AM +0100, Uwe Kleine-König wrote:
> > > > So working copy and cache are at refs/tags/sgu/mxs-amba-uart, HEAD
> > > > points to refs/heads/sgu/mxs-amba-uart
> > >
> > > Yeah, we generally resolve ambiguities in favor of the tag (and that
> > > warning comes from deep within get_sha1_basic). So the real bug here is
> > > that it still said "Switched to branch", which is totally wrong.
> > I wonder how I can resolve the ambiguity when calling checkout. (Well
> > apart from changing either branch name or tag name)
> >
> > git checkout refs/heads/sgu/mxs-amba-uart results in a detached HEAD.
>
> You can't disambiguate to the branch without going to a detached HEAD in
> the current code; it's just broken[1].
>
> With the patch here:
>
> http://article.gmane.org/gmane.comp.version-control.git/164986
>
> it will disambiguate to the branch by default, and if you want the tag,
> you can do:
>
> git checkout tags/sgu/mxs-amba-uart
that's fine.
> [1]: You can't do it with checkout, that is. You can still hack around
> it with:
>
> branch=refs/heads/sgu/mxs-amba-uart
> git read-tree -m -u $branch &&
> git symbolic-ref HEAD $branch
I did
git checkout refs/heads/sgu/mxs-amba-uart
git symbolic-ref HEAD refs/heads/sgu/mxs-amba-uart
:-)
Uwe
>
> which is a simplified version of what checkout is doing.
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [Bug] Gitweb corrupting files?
From: Jakub Narebski @ 2011-01-12 18:05 UTC (permalink / raw)
To: Severin Gehwolf; +Cc: git, Jakub Narebski
In-Reply-To: <AANLkTim84sSWr=WRgjiY=Y3Mq7Tgojv9CpLrNjQMJfHR@mail.gmail.com>
Severin Gehwolf <jerboaa@gmail.com> writes:
> It appears that Gitweb corrupts files when it is being used for
> creating compressed tarballs of sources.
E.g. http://egit.eclipse.org/w/?p=egit.git;a=snapshot;h=6b528445c3e543688b990e0a631c5f0238b02741;sf=tbz2
error in egit/org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/BranchSelectionDialog.java
> A more precise description of the behaviour I'm experiencing is here:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317882
Couldn't you post summary of the above here?
> Unfortunately I have no knowledge about the version in use at eclipse.org.
It's git and gitweb version 1.6.4.4.
>From original bugreport:
And it built fine. Then, I tried checking out sources from command line using
the git client:
git clone git://egit.eclipse.org/egit.git egit
cd egit
git checkout 6b528445c3e543688b990e0a631c5f0238b02741
cd ..
tar -cjf egit_test.tar.bz2 egit
This should be
$ git archive --format=tar 6b528445c3e543688b990e0a631c5f0238b02741 |
bzip2 > egit_test.tar.bz2
just to make sure that it isn't a problem of how tarballs are created when
using the above URL. It seems the file in the repository is corrupted (although
I'm not entirely convinced). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Git version 1.6.4.4 is long since fixing bug with not using ':raw'
(binary) output layer with binary files. Also I don't see how it
could have corrupted only 2 files, without making [compressed] archive
un-compressable (invalid).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-12 17:46 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20110112091130.GC24920@pengutronix.de>
On Wed, Jan 12, 2011 at 10:11:30AM +0100, Uwe Kleine-König wrote:
> > > So working copy and cache are at refs/tags/sgu/mxs-amba-uart, HEAD
> > > points to refs/heads/sgu/mxs-amba-uart
> >
> > Yeah, we generally resolve ambiguities in favor of the tag (and that
> > warning comes from deep within get_sha1_basic). So the real bug here is
> > that it still said "Switched to branch", which is totally wrong.
> I wonder how I can resolve the ambiguity when calling checkout. (Well
> apart from changing either branch name or tag name)
>
> git checkout refs/heads/sgu/mxs-amba-uart results in a detached HEAD.
You can't disambiguate to the branch without going to a detached HEAD in
the current code; it's just broken[1].
With the patch here:
http://article.gmane.org/gmane.comp.version-control.git/164986
it will disambiguate to the branch by default, and if you want the tag,
you can do:
git checkout tags/sgu/mxs-amba-uart
-Peff
[1]: You can't do it with checkout, that is. You can still hack around
it with:
branch=refs/heads/sgu/mxs-amba-uart
git read-tree -m -u $branch &&
git symbolic-ref HEAD $branch
which is a simplified version of what checkout is doing.
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-12 17:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, git
In-Reply-To: <7vd3o232xk.fsf@alter.siamese.dyndns.org>
On Wed, Jan 12, 2011 at 01:07:51AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I'm not sure. And to be honest I don't really care, because I think
> > people with ambiguous refs are little bit crazy anyway (after all, in
> > the current code it simply calls die()). But I think there is some
> > argument to be made that due to tracking, start_point is not _just_
> > a regular ref. We do care about its branchiness.
>
> I do not really care either myself, and if
>
> git branch --track foo heads/ambiguity
> git branch --track foo tags/ambiguity
>
> allows the user to differentiate between the branch and the tag, it would
> be more than sufficient.
It does already. So I am inclined to leave it alone, then. I doubt
anyone actually cares, and if they do, they will get an error message,
after which they can manually disambiguate themselves.
So let's leave it at the mega-patch I posted earlier.
-Peff
^ permalink raw reply
* Re: [Bug] Gitweb corrupting files?
From: J.H. @ 2011-01-12 17:08 UTC (permalink / raw)
To: Severin Gehwolf; +Cc: git
In-Reply-To: <AANLkTim84sSWr=WRgjiY=Y3Mq7Tgojv9CpLrNjQMJfHR@mail.gmail.com>
On 01/12/2011 08:05 AM, Severin Gehwolf wrote:
> Hi,
>
> It appears that Gitweb corrupts files when it is being used for
> creating compressed tarballs of sources.
>
> A more precise description of the behaviour I'm experiencing is here:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=317882
>
> Unfortunately I have no knowledge about the version in use at eclipse.org.
That's a fairly old version of gitweb running (1.6.6.4), and it looks
like it's stock gitweb (I.E. not the caching version). The file itself
(the .bz2 anyway) is a valid, and complete .bz2, as well as the .tar
file extracts cleanly.
That would indicate, that if there is corruption, it is happening in the
git process itself that generates the tarball, and not in gitweb itself.
Best plan would be to upgrade to the latest code of gitweb and git and
see if the problem still persists, and if it does be able to get us a
tarball and url that has the corruption.
- John 'Warthog9' Hawley
^ permalink raw reply
* Git Rebase blows away GIT_AUTHOR_NAME
From: JT Olds @ 2011-01-12 16:15 UTC (permalink / raw)
To: git
I asked this in #git on freenode, and I've also spent a while
searching the internet for anyone with any similar issues, but I can't
seem to find anyone or anything that knows what's going on.
On every fresh install of Ubuntu that I have used (by default, I use
ecryptfs for my home directory, which of course has its own set of
silly Git errors right now), when I clone from a remote repository,
have changes local to me, and changes on the remote repository, do
'git pull --rebase', occasionally my GIT_AUTHOR_NAME gets set to my
GIT_AUTHOR_EMAIL on my changes that get applied on top of the remote
changes.
This is incredibly frustrating, so much so that my workflow now
includes running an alias to git filter-branch that fixes this.
Notable things: so far I have only had a remote server hosted by
Gerrit, but I can't imagine how changes on the remote git server could
possibly affect my local changes. Like I said, I'm using ecryptfs, and
I'm using vanilla Git from the latest stable Ubuntu, though I've had
this problem on Ubuntus for a few releases now.
Anyone have any idea why this might happen?
-JT
^ permalink raw reply
* [Bug] Gitweb corrupting files?
From: Severin Gehwolf @ 2011-01-12 16:05 UTC (permalink / raw)
To: git
Hi,
It appears that Gitweb corrupts files when it is being used for
creating compressed tarballs of sources.
A more precise description of the behaviour I'm experiencing is here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=317882
Unfortunately I have no knowledge about the version in use at eclipse.org.
Thanks,
Severin
^ permalink raw reply
* Re: working with a large repository and git svn
From: Wesley J. Landaker @ 2011-01-12 15:30 UTC (permalink / raw)
To: Joe Corneli; +Cc: git
In-Reply-To: <AANLkTimKbS3ECzOaGtNgvx7DThJGH_DkPmg4ehKXGtwc@mail.gmail.com>
On Tuesday, January 11, 2011 18:27:10 Joe Corneli wrote:
> I am experiencing trouble with git svn, trying to import a
> large repository (7.9 gigs, ~54000 commits) from Git into
> SVN.
>
> This has failed in a couple of different ways, depending
> on the operating environment. With Git version 1.7.3.5
> running on Ubuntu 9.10, in the final step
>
> git svn dcommit --no-rebase
>
> of the formula described below, I get:
>
> failing with "Can't fork at /usr/share/perl/5.10.0/Git.pm line 1261."
>
> after committing just over 2000 revisions.
I haven't tried importing 8 GB from Git to Subversion, but I have used Git
against existing huge Subversion repositories that are >= 10 GB with little
trouble, other than that it takes forever because Subversion is slow.
Here are some thoughts on how I'd approach what you are doing. Realize that
no matter what, it's still probably going to take "forever" (e.g. run it
over the weekend).
1) Sounds like git-svn is running out of resources on your machine --
that's probably a bug, but work around it: Don't dcommit all 20000 revisions
at once. Maybe write a shell script that goes through and dcommits a 100
commits at a time.
2) Do you need the full history to be in SVN? Can you rebase/squash large
parts together and thus need to commit less revisions in the first place?
3) I love git-svn for working with Subversion repositories, but you could
consider a different tool, like tailor, if you can't make git-svn do what
you want. I have also heard talk (but I don't know the state of things) of
people working on a fast-import tool for SVN, so you could git-fast-export
and svn-fast-import in a big batch.
4) Does 8 GB of data really belong in the same repository? Maybe it should
really be split up and used with git submodules or SVN externals? That may
make things easier to work with in the long term.
5) Do you really want to be going from Git, to Subversion? That seems like
a big step backwards. =)
In any case, good luck!
^ permalink raw reply
* Forcing re-reading files with unchanged stats
From: Maaartin @ 2011-01-12 14:07 UTC (permalink / raw)
To: git
There are files in my working tree which changes, but their size and mtime
remains the same (I know it's strange, but it's useful). Can I make git to re-
read them all, so it recognizes the change? Ideally, using a configuration
variable. The repo is fairly small, so speed is no issue here.
^ permalink raw reply
* Re: [PATCH 05/31] rebase: improve detection of rebase in progress
From: Martin von Zweigbergk @ 2011-01-12 10:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin von Zweigbergk, git, Johannes Schindelin, Johannes Sixt,
Christian Couder
In-Reply-To: <alpine.DEB.1.10.1012282104320.29381@debian>
On Tue, 28 Dec 2010, Martin von Zweigbergk wrote:
>
> On Tue, 28 Dec 2010, Junio C Hamano wrote:
>
> > Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> >
> > > Currently, the existence of rebase-merge/ is tested with 'test -d',
> > > while the existence of rebase-apply/ is tested by creating the
> > > directory and then deleting it again. Any good reason for this?
> >
> > I don't recall how the merge side reached the current shape of the code,
> > but I think the rebase-apply one was that we wanted to make sure not only
> > we don't have a directory but also we actually _can_ create one. If
> > somebody had a bad permission set, "test -d" wouldn't help us much. We
> > would fail later and error diagnosis codepath should do the right thing
> > anyway, so it is not a correctness issue, but is more about attempting to
> > notice an error early rather than late.
>
> Yeah, I was wondering if that might have been the reason. Why would
> anyone set such permissions on .git (keep in mind that I am no
> Linux/Unix expert)?
>
> I saw that the code was introduced [1] when the directory was called
> .dotest and I believe this directory was created at the top level
> (i.e. a sibling to .git). Could it be that it was reasonable for the
> user to set such permissions back then (on the top level dir), but not
> any longer (on the .git dir)?
>
>
> Either way, if it is good to have the that check for rebase-apply/,
> wouldn't it be good to have for rebase-merge/ as well?
>
> /Martin
>
>
> [1] 7f4bd5d (rebase: one safety net, one bugfix and one optimization.,
> 2005-11-28)
>
I'm working on a re-roll. Any input on this?
^ 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