* Re: git history and file moves
From: Michael J Gruber @ 2008-10-22 12:38 UTC (permalink / raw)
To: Lin Ming; +Cc: Alex Riesen, git, Moore, Robert
In-Reply-To: <81b0412b0810220419q43f6985fs1c608e3d3cbcf8f3@mail.gmail.com>
Alex Riesen venit, vidit, dixit 10/22/08 13:19:
> 2008/10/22 Lin Ming <ming.m.lin@intel.com>:
>> I'm looking for a way to move files to a new directory and have the
>> full history follow the file automatically. Is this possible?
>>
>> I know about --follow, but I want the history to just follow the file
>> transparently. ...
>
> Of all Git tools, what does not do this "transparently" or "automatically"?
> How more transparent do you imagine this?
> What do you think should follow what?
>
> I ask, because it is hard to understand what exactly is it you're missing:
> merge support (which we have), git log listing the files as copied/renamed
> (which is what --follow is for, and the suggestion for you is to make an
> alias or something), git blame (ever looked at git gui blame?) or gitk
> (which follows renames in default configuration)
>
>> Also, we have a git web interface and we want the full
>> history for the moved files to be available.
>
> It is available. Whether it is shown is another question. git-web can
> be improved (or just configured?)
By default, gitweb uses "-M" for diff. You can specify all options (-C,
-CC, -B) using "@diff_opts" in the config file for gitweb.cgi - if that
is what you are using. Is it?
Anyways, using default configs for git log and gitweb.cgi both of them
show the full history (renames, history before and after) for me here,
using current git (1.6.0.3.514.g2f91b). What is your setup?
Michael
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 12:39 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano
In-Reply-To: <bb6f213e0810220232p2e7fe3daoa32f46fbe5bef2ac@mail.gmail.com>
On Wed, Oct 22, 2008 at 01:32:56PM +0400, Alexander Gavrilov wrote:
> From the output it seems that what fails is "-f cp1251 -t sjis" and
> "-f utf-8 -t sjis" (remember that blame --incremental produces its
Oh, indeed. Converting to and from utf-8 seems to work, but not between
cp1251 and sjis:
$ iconv -f SJIS -t UTF-8 sjis.txt | sed s/SJIS/UTF8/ >test &&
> cmp test utf8.txt && echo ok
ok
$ iconv -f UTF-8 -t SJIS utf8.txt | sed s/UTF8/SJIS/ >test &&
> cmp test sjis.txt && echo ok
ok
$ iconv -f SJIS -t CP1251 sjis.txt
Not supported SJIS to CP1251
$ iconv -f CP1251 -t SJIS cp1251.txt
Not supported CP1251 to SJIS
So I think it is simply a limitation of the platform with respect to the
particular encodings used. There is a similar problem in t3900, I think,
with EUCJP and ISO-2022-JP. I assume one _can_ install these encodings
for Solaris, but the admins of my box haven't done so (and this is a
production box that I can't ask for such things on).
> blame for some reason actually tries to convert to an entirely
> different encoding. If tests 4 and 5 pass, you can try adding
> --encoding=shift-jis to test 2 to check it.
Tests 2, 3, and 4 fail. Test 5 does pass.
-Peff
^ permalink raw reply
* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Jeff King @ 2008-10-22 12:51 UTC (permalink / raw)
To: Stephen Haberman; +Cc: gitster, git
In-Reply-To: <759654ef1f1781cd2b102e21c6f972b065560398.1224055978.git.stephen@exigencecorp.com>
On Wed, Oct 15, 2008 at 02:44:36AM -0500, Stephen Haberman wrote:
> + if [ "$fast_forward" == "t" ]
This one even fails on my Linux box. :) "==" is a bash-ism.
-Peff
^ permalink raw reply
* Re: git archive
From: Deskin Miller @ 2008-10-22 13:08 UTC (permalink / raw)
To: kenneth johansson; +Cc: git
In-Reply-To: <gdmp0p$92r$1@ger.gmane.org>
On Wed, Oct 22, 2008 at 08:42:01AM +0000, kenneth johansson wrote:
> I was going to make a tar of the latest stable linux kernel.
> Done it before but now I got a strange problem.
>
> >git archive --format=tar v2.6.27.2
> fatal: Not a valid object name
I had the same thing happen to me, while trying to make an archive of Git.
Were you perchance working in a bare repository, as I was? I spent some time
looking at it and I think git archive sets up the environment in the wrong
order, though of course I never finished a patch so I'm going from memory:
After looking at the code again, I think the issue is that git_config is called
in builtin-archive.c:cmd_archive before setup_git_directory is called in
archive.c:write_archive. The former ends up setting GIT_DIR to be '.git' even
if you're in a bare repository. My coding skills weren't up to fixing it
easily; moving setup_git_directory before git_config in builtin-archive caused
last test of t5000 to fail: GIT_DIR=some/nonexistent/path git archive --list
should still display the archive formats.
Another vote for from me for the discussion carried on here:
http://article.gmane.org/gmane.comp.version-control.git/98800
Deskin Miller
^ permalink raw reply
* Re: git add --patch newfile doesn't add newfile to cache ?
From: Marc Weber @ 2008-10-22 13:12 UTC (permalink / raw)
To: git
In-Reply-To: <20081020235049.GA23120@coredump.intra.peff.net>
On Mon, Oct 20, 2008 at 07:50:50PM -0400, Jeff King wrote:
> On Mon, Oct 20, 2008 at 04:36:36PM +0200, Marc Weber wrote:
>
> > Is this desired behaviour?
> > [...]
> > git init
> > echo test > test
> > git add --patch test
> > echo "running status, nothing has been added"
> > git status
>
> I think your example makes sense, but nobody ever really tried it
> before. [..]
I came across this use case because I'm lazy. eg
git add --patch file-to-be-committed-partly newfile
is shorter than
git add --patch file-to-be-committed-partly
git add newfile
> I use "git add -p" all the time, but almost always when I am
> adding a new file, I add the whole contents.
>
> I think there are two ways to go about fixing it:
>
> - in git-add--interactive.perl, the function patch_update_cmd
> explicitly looks at the list of modified files. It would have to
> also check for untracked files, which is easy. But we also need to
> keep track of which files are modified and which are untracked
> through the whole patching procedure, which is a bit more invasive.
>
> - the recently-added "git add -N" adds an empty file into the index,
> at which point we could add content in the normal way. So:
>
> git add -N test
> git add -p test
>
> should just work (but obviously requires two steps from the user).
> You could do something more automatic like the patch below, but I
> think the semantics aren't quite right. If you stage nothing for a
> newly added file, then you still end up with an empty version of the
> staged file in the index. I would expect the semantics to be:
>
> 1. if you stage any content, then the file is added to the index
> with that content
>
> 2. if you stage no content, then the file remains untracked
> ---
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> [...]
> sub patch_update_cmd {
> + my @new = list_untracked();
> + if (@new) {
> + system(qw(git add -N), @new)
> + and die "git add reported failure";
> + }
> +
I've tried the patch. However I'm not fully satisified.
I often use --patch to have another second look at each change to be
committed. Your patch adds new files to the cache silently without
giving the user the change to omit or edit the patch. But exatly that's
the reason I'm using --patch. So maybe I can work on this in some days..
Maybe I've also injected those lines into the wrong git version
(1.6.0.2.GIT)
May I try rewriting your semantics proposal to this ?
1) when using git add --patch untracked-file the user should be
given the default patch view (only containing + lines)
so that he can use edit to only commit parts of the file in the
usual way. (I guess this is similar to having used git add -N
before, I haven't tried yet)
2) if he wants to skip the entire patch / file nothing should be
added to the index.
Thanks for your reply.
Sincerly
Marc Weber
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Jeff King @ 2008-10-22 13:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Ingo Molnar, git
In-Reply-To: <m3ljwgj3xy.fsf@localhost.localdomain>
On Wed, Oct 22, 2008 at 03:50:52AM -0700, Jakub Narebski wrote:
> About printing either forward (git-describe, e.g. v1.6.0.2-590-g67f6062)
> or backward (git-name-rev, e.g. tags/v1.6.0-rc2~8): you can use
> git-name-rev in filter mode (git log ... | git name-rev --stdin), or
> "git log --decorate", or '%d' in --pretty format specifier (this is very
> new thing).
The "--decorate" and "%d" code just decorates branch _tips_. My
impression is that he wanted to see the branch mentioned even if the
commit was not at the tip. It would be possible to extend this to print
name-rev output, but it would be computationally and memory-intensive, I
suspect.
-Peff
^ permalink raw reply
* Re: Does a `git pull' write to the origin repository in any way?
From: Marc Weber @ 2008-10-22 13:25 UTC (permalink / raw)
To: git
In-Reply-To: <a65d095e0810220200q42936427o917cdac067d04135@mail.gmail.com>
On Wed, Oct 22, 2008 at 08:00:11PM +1100, Brett Ryan wrote:
> Greetings, the reason I ask this question is because my pattern of
> development is to create local source git repositories on my home
> directory, then pull them to the central location. I found myself
> getting the error `unable to create temporary sha1 filename
> .git/objects/11: File exists' which after investigation found that
> there were paths in `.git/objects/' owned by root which is who I use
> to do the pull from my home directory using sudo.
Aeh.. about which repo are you talking here? I guess it's not the one
owned by root because otherwise this would be normal..
Hi Brett, I'm not sure where the problem comes form. But I feel your dev
cycle is kind of wired.
If you can login as root using ssh you can also do it the "normal" (?)
way:
# user dir
git remote add root_repo ssh://root@localhost/path-to-root-repo
git pull root_repo # then resolve conflicts if any
git push root_repo # update the root repo
This way you always have conflicts in your local repo and never on the
root one which is preferable (IMHO)..
git-fetch doesn't list a way to access another repo by "su(do)" which
might be the best way here ? This could be convinient because you
would'nt have to setup an extra group to access the same repo as root
and user (?)
You're right that git pull *should not* modify any files from the repo
its pulling from.. But I don't know enough about git internals to say
more about this. All I know is that git clone might have created some
hardlinks.. But I'm not sure how this interfers with file permissions.
I hope someone else can give a more accurate reply.
Marc Weber
^ permalink raw reply
* Re: git add --patch newfile doesn't add newfile to cache ?
From: Jeff King @ 2008-10-22 13:29 UTC (permalink / raw)
To: Marc Weber; +Cc: git
In-Reply-To: <20081022131232.GL3988@gmx.de>
On Wed, Oct 22, 2008 at 03:12:32PM +0200, Marc Weber wrote:
> > sub patch_update_cmd {
> > + my @new = list_untracked();
> > + if (@new) {
> > + system(qw(git add -N), @new)
> > + and die "git add reported failure";
> > + }
> > +
>
>
> I've tried the patch. However I'm not fully satisified.
> I often use --patch to have another second look at each change to be
> committed. Your patch adds new files to the cache silently without
> giving the user the change to omit or edit the patch. But exatly that's
> the reason I'm using --patch. So maybe I can work on this in some days..
> Maybe I've also injected those lines into the wrong git version
> (1.6.0.2.GIT)
Yes, you need to use the current 'master' branch for the "-N" feature.
The point of "-N" is to say "this is a file I want to track, but don't
add any contents yet." So it does your part 1:
> 1) when using git add --patch untracked-file the user should be
> given the default patch view (only containing + lines)
> so that he can use edit to only commit parts of the file in the
> usual way. (I guess this is similar to having used git add -N
> before, I haven't tried yet)
But not your part 2:
> 2) if he wants to skip the entire patch / file nothing should be
> added to the index.
If you add _no_ contents, you still end up with the "this is a file I
want to track" part, but with no contents. And I agree it should stage
nothing, which is why this is an unsatisfactory solution (and why I
didn't clean up the patch and send it to Junio for inclusion).
-Peff
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-22 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810211856090.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 10/22/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I propose this change in semantics:
>
> - setup_git_directory_gently(): rename to discover_git_directory(),
> and avoid any chdir() at all.
> - setup_git_directory(): keep the semantics that it chdir()s to the
> worktree, or to the git directory for bare repositories.
>
> Using _gently() even for RUN_SETUP builtins should solve the long standing
> pager problem, too.
One more thing: "git foo -h" with RUN_SETUP won't run if repository is
not found. Maybe just drop RUN_SETUP and let subcommands call
setup_git_directory()
--
Duy
^ permalink raw reply
* Re: Does a `git pull' write to the origin repository in any way?
From: Brett Ryan @ 2008-10-22 14:27 UTC (permalink / raw)
To: Marc Weber, git
In-Reply-To: <20081022132517.GM3988@gmx.de>
Thanks Marc. I agree the dev cycle is a little strange, though we're
still using a 4GL environment (Progress) from the 70's where all the
developers have no prior experience to version control except for
renaming files to ${name}.yyyymmdd.
My apologies for being a little light headed I've only been using git
for about a week now, currently I'm the main merger for CVS and
looking for an alternative. First impressions of `git' to me are
fantastic and it seems to fit right, what I need to do is figure out a
good dev cycle that my peers can use as they're all used to working
int he same directory and just simply yelling out to each other "I'm
about to edit file {x}", making me cringe each time.
Anyway Marc your answer was all I'm after, it could have been
something I goofed, just needed clarification that a pull wasn't going
to touch the rep that the pull is pulling from.
Thanks,
-Brett
On Thu, Oct 23, 2008 at 12:25 AM, Marc Weber <marco-oweber@gmx.de> wrote:
> On Wed, Oct 22, 2008 at 08:00:11PM +1100, Brett Ryan wrote:
>> Greetings, the reason I ask this question is because my pattern of
>> development is to create local source git repositories on my home
>> directory, then pull them to the central location. I found myself
>> getting the error `unable to create temporary sha1 filename
>> .git/objects/11: File exists' which after investigation found that
>> there were paths in `.git/objects/' owned by root which is who I use
>> to do the pull from my home directory using sudo.
> Aeh.. about which repo are you talking here? I guess it's not the one
> owned by root because otherwise this would be normal..
>
> Hi Brett, I'm not sure where the problem comes form. But I feel your dev
> cycle is kind of wired.
> If you can login as root using ssh you can also do it the "normal" (?)
> way:
>
> # user dir
> git remote add root_repo ssh://root@localhost/path-to-root-repo
> git pull root_repo # then resolve conflicts if any
> git push root_repo # update the root repo
>
> This way you always have conflicts in your local repo and never on the
> root one which is preferable (IMHO)..
>
> git-fetch doesn't list a way to access another repo by "su(do)" which
> might be the best way here ? This could be convinient because you
> would'nt have to setup an extra group to access the same repo as root
> and user (?)
>
> You're right that git pull *should not* modify any files from the repo
> its pulling from.. But I don't know enough about git internals to say
> more about this. All I know is that git clone might have created some
> hardlinks.. But I'm not sure how this interfers with file permissions.
>
> I hope someone else can give a more accurate reply.
>
> Marc Weber
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* error: packfile while git fsck
From: Nicolas Ferre @ 2008-10-22 14:06 UTC (permalink / raw)
To: git
Hi all,
(please cc me on response)
I am facing error during git status & git fsck on my tree.
This tree is cloned from various linux kernel trees.
Here are a sample of the error I see :
$ git fsck
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
[..]
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
dangling blob fe130d58453393f15e0db82bca18f35998689a87
dangling commit 2515ddc6db8eb49a79f0fe5e67ff09ac7c81eab4
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
dangling commit 6bb7a935489dab20802dde6c2cb7d8582f4849bf
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
dangling commit 4aba41ea8bdc1b475861f5e5c1649ab20251090c
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
[..]
$ git verify-pack .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
nferre@bendor:linux-2.6-arm > git verify-pack .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
fatal: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
What can I do to recover my git archive ?
Did I do something wrong (merging files while fetching) ?
Is it related to a known issue (I cannot figure out if it is
after some googling) ?
Thanks for your help. Regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: error: packfile while git fsck
From: Nicolas Pitre @ 2008-10-22 14:52 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: git
In-Reply-To: <48FF337F.3050505@atmel.com>
On Wed, 22 Oct 2008, Nicolas Ferre wrote:
> Hi all,
> (please cc me on response)
>
> I am facing error during git status & git fsck on my tree.
> This tree is cloned from various linux kernel trees.
>
> Here are a sample of the error I see :
>
> $ git fsck
> error: packfile
> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not
> match index
> error: packfile
> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be
> accessed
[...]
What git version?
> Did I do something wrong (merging files while fetching) ?
Unlikely.
Nicolas
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-22 14:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810211856090.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 10/22/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I propose this change in semantics:
>
> - setup_git_directory_gently(): rename to discover_git_directory(),
> and avoid any chdir() at all.
> - setup_git_directory(): keep the semantics that it chdir()s to the
> worktree, or to the git directory for bare repositories.
>
> Using _gently() even for RUN_SETUP builtins should solve the long standing
> pager problem, too.
Also, from [1] may be only set default git_dir in setup_git_env()
after setup_git_directory() has been called and before
setup_work_tree() is called (if any)? If not, die().
[1] http://article.gmane.org/gmane.comp.version-control.git/98849
--
Duy
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-22 14:59 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Peter Harris, git
In-Reply-To: <48FDF28A.9060606@xiplink.com>
Marc Branchaud venit, vidit, dixit 10/21/08 17:17:
> I believe git lets you track the origin's _branches_ not the origin's
> _remotes_. I don't think --mirror does what I'm looking for, because
> (side effects aside) it only deals with branches, not remotes.
>
> I find myself getting confused, and I think it's because the files in
> .git/refs/remotes/ are indeed tracking branches on remote repositories.
> So I think our conversation gets a bit circular because our ideas of a
> "remote" differ.
Yes, I think there are multiple uses:
- a remote repository (referenced to by an URL)
- a remote config (as created by git remote add)
- a remote branch (a branch in your local repo which is a copy of a
branch in a remote repo; stored under refs/remotes, never to be modified
locally)
- a (remote) tracking branch (a local branch which is set up to pull
from a remote branch by default)
Only the first of these 4 is something resides "remotely". Of course,
"remote URL" could be a path on the local file system or even ".".
> "git remote add" does two things (maybe more?): It adds a [remote]
> section to the .git/config file, and it adds a branch reference in
> .git/refs/remotes/.
Yes.
> I think what I'd like is for the clone to be able
> to obtain both these things from the origin. The reason I think it's
> useful is that it would let the clone pull directly from the origin's
> remote repositories, without having to directly specify the remote
> repository's URL and branch name.
>
> Fundamentally, I'm looking to do exactly
>
> clone/$ git pull -s subtree /path/to/ThingOne master
>
> i.e. pull stuff from one of main's remotes directly into the clone. But
> I want to replace the "/path/to/ThingOne master" part with something
> that means "use whatever URL and branch name was defined in the origin
> for this remote".
>
> My questions are: Am I right in thinking this is desirable?
I've got the strong impression you desire it...
Seriously, it seems desirable in cases where the remote URL changes
frequently; say, because the upstream maintainer (maintainer of
ThingOne) gets hit by a bus frequently, or walks the wrong streets in LA
at the wrong time of the day. (I guess my seriousness ended with the
";".) Clones would follow those changes transparently then (if that
feature existed).
> Is there
> already some way to do this?
None that I know of.
> If not, is it something worth
> implementing? (I'm happy to roll up my own sleeves here...)
First you should decide whether it is worth for you. Comments on the
list tend to kick in once people see a proposed implementation. A viable
strategy could be, mimicking git submodule behaviour in part:
- Implement "git remote export reponame" which takes an existing remote
config from .git/config, writes it to .gitremotes and checks in (or
better: stages for commit) the file .gitremotes [you would use this on main]
- Implement "git remote import" which reads the file .gitremotes and
adds remote config to .git/config. [you would use this on clones]
- Change "git remote update" to take updates to .gitremotes into account
before doing its usual routine (perhaps based on a config with default
off, or a command line option, or better both)
Downside is that .gitremotes is tracked would show up as a file in the
repo, but I can't come up with a better way which is as simple as the
above. .gitremotes could be stored in a specially named branch, though.
> I hope that clarifies things. Sorry for taking so long to get here!
Don't worry. I take partial blame ;)
And thanks for trying to match up your workflow with git.
Cheers,
Michael
^ permalink raw reply
* Start git svn clone at specific revision for cloning subprojects in large svn repositories?
From: Jeff Kowalczyk @ 2008-10-22 15:00 UTC (permalink / raw)
To: git
I would like to git svn clone subprojects from a large community
subversion repository (plone collective).
The repository is currently at 74K commits, but subprojects of interest
are typically much more recent, and their initial import revision is known.
I would like to avoid a) unnecessary traffic to the svn server and b)
the very long delay in git svn cloning these subprojects.
Is there a way to specfiy a starting revision to git svn clone?
Thanks.
^ permalink raw reply
* Re: Start git svn clone at specific revision for cloning subprojects in large svn repositories?
From: Jacob Helwig @ 2008-10-22 15:07 UTC (permalink / raw)
To: Jeff Kowalczyk; +Cc: git
In-Reply-To: <pan.2008.10.22.15.00.21.403423@yahoo.com>
On Wed, Oct 22, 2008 at 08:00, Jeff Kowalczyk <jtk@yahoo.com> wrote:
> I would like to git svn clone subprojects from a large community
> subversion repository (plone collective).
>
> The repository is currently at 74K commits, but subprojects of interest
> are typically much more recent, and their initial import revision is known.
>
> I would like to avoid a) unnecessary traffic to the svn server and b)
> the very long delay in git svn cloning these subprojects.
>
> Is there a way to specfiy a starting revision to git svn clone?
>
> Thanks.
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Try git svn init, then git svn fetch --revision <revision#>:HEAD.
This is what I use for some of our larger projects at work.
^ permalink raw reply
* Re: Start git svn clone at specific revision for cloning subprojects in large svn repositories?
From: Michael J Gruber @ 2008-10-22 15:08 UTC (permalink / raw)
To: Jeff Kowalczyk; +Cc: git
In-Reply-To: <pan.2008.10.22.15.00.21.403423@yahoo.com>
Jeff Kowalczyk venit, vidit, dixit 10/22/08 17:00:
> I would like to git svn clone subprojects from a large community
> subversion repository (plone collective).
>
> The repository is currently at 74K commits, but subprojects of interest
> are typically much more recent, and their initial import revision is known.
>
> I would like to avoid a) unnecessary traffic to the svn server and b)
> the very long delay in git svn cloning these subprojects.
>
> Is there a way to specfiy a starting revision to git svn clone?
Your friendly man page provider says:
-r <ARG>, --revision <ARG>
Used with the fetch command.
This allows revision ranges for partial/cauterized history to
be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric
ranges), $NUMBER:HEAD, and BASE:$NUMBER are all supported.
This can allow you to make partial mirrors when running
fetch; but is generally not recommended because history
will be skipped and lost.
Usage of "Scroll Down" is strongly advised when viewing git help svn ;)
Michael
P.S.: It works nicely, don't mind the warning in the man page if you
know the start rev for sure.
^ permalink raw reply
* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Johannes Schindelin @ 2008-10-22 15:21 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Haberman, gitster, git
In-Reply-To: <20081022125149.GA17092@coredump.intra.peff.net>
Hi,
On Wed, 22 Oct 2008, Jeff King wrote:
> On Wed, Oct 15, 2008 at 02:44:36AM -0500, Stephen Haberman wrote:
>
> > + if [ "$fast_forward" == "t" ]
>
> This one even fails on my Linux box. :) "==" is a bash-ism.
Did we not also prefer "test" to "["?
Ciao,
Dscho
^ permalink raw reply
* Re: error: packfile while git fsck
From: Nicolas Ferre @ 2008-10-22 15:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0810221049340.26244@xanadu.home>
Nicolas Pitre :
> On Wed, 22 Oct 2008, Nicolas Ferre wrote:
>
>> Hi all,
>> (please cc me on response)
>>
>> I am facing error during git status & git fsck on my tree.
>> This tree is cloned from various linux kernel trees.
>>
>> Here are a sample of the error I see :
>>
>> $ git fsck
>> error: packfile
>> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not
>> match index
>> error: packfile
>> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be
>> accessed
> [...]
>
> What git version?
$ git --version
git version 1.5.3.7
Kind regards,
--
Nicolas Ferre
^ permalink raw reply
* [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Shawn O. Pearce @ 2008-10-22 15:42 UTC (permalink / raw)
To: git
My "bundle related secret project" was released yesterday by Google
as part of the Android open source release event. (I've mentioned
it before on-list in the context of a modified "git status" output.)
Google developed two tools, repo and Gerrit, and open sourced them
under the Apache License:
http://android.git.kernel.org/?p=tools/repo.git
http://android.git.kernel.org/?p=tools/gerrit.git
git://android.git.kernel.org/tools/repo.git
git://android.git.kernel.org/tools/gerrit.git
repo is a Python application to bind together Git repositories,
something like "git submodule", except it can track a project's
branch rather than a specific Git commit. repo is also able to
natively import a tarball or zip file and use it to initialize a
repository from an upstream source, then apply git based changes
on top of that tarball. In other words, repo is (more or less)
built to manage an OS distribution, in Git.
Gerrit is a web based code review system, forked off the open
sourced Rietveld code review system. Gerrit runs on the highly
scaleable Google App Engine platform, but probably could be ported
to an open-source MySQL or PostgreSQL backend if people really
wanted to do that.
You can read some more of how Android has applied these tools to
its development process here:
http://source.android.com/download
http://source.android.com/submit-patches/workflow
http://source.android.com/download/using-repo
Although the current tool documentation is only on the Android
site, both the repo and Gerrit tools are not specific to Android
and are designed to be applied to any project that wants to use a
similar process.
repo and Gerrit are actually developed with themselves. You can
use repo to fetch repo:
curl http://android.git.kernel.org/repo >~/bin/repo
chomd a+x ~/bin/repo
mkdir myrepo
cd myrepo
repo init -u git://android.git.kernel.org/tools/manifest.git
repo sync
The "git status" output I was talking about before is the "repo
status" subcommand, e.g.:
$ echo '# test' >>repo/repo ; # modify a tracked file
$ repo status
project repo/ (*** NO BRANCH ***)
-m repo
--
Shawn.
^ permalink raw reply
* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Fredrik Skolmli @ 2008-10-22 15:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Stephen Haberman, gitster, git
In-Reply-To: <alpine.DEB.1.00.0810221721370.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Wed, Oct 22, 2008 at 05:21:53PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 22 Oct 2008, Jeff King wrote:
>
> > On Wed, Oct 15, 2008 at 02:44:36AM -0500, Stephen Haberman wrote:
> >
> > > + if [ "$fast_forward" == "t" ]
> >
> > This one even fails on my Linux box. :) "==" is a bash-ism.
>
> Did we not also prefer "test" to "["?
We did.
Documentation/CodingGuidelines, line 51:
- We prefer "test" over "[ ... ]".
--
Kind regards,
Fredrik Skolmli
^ permalink raw reply
* Terminology question: "tracking" branches
From: Björn Steinbrink @ 2008-10-22 16:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Marc Branchaud, Peter Harris, git
In-Reply-To: <48FF3FEE.8020209@drmicha.warpmail.net>
On 2008.10.22 16:59:58 +0200, Michael J Gruber wrote:
> - a remote branch (a branch in your local repo which is a copy of a
> branch in a remote repo; stored under refs/remotes, never to be modified
> locally)
> - a (remote) tracking branch (a local branch which is set up to pull
> from a remote branch by default)
(Remote) tracking branches are actually what you called remote branches,
at least according to the git glossary. But I wonder, what is the right
term for a branch that has the --track setup for pull?
On #git I usually fall back to some variation of "a branch that is
configured for 'git pull'" or something similarly verbose (and maybe
that's even partially wrong/inaccurate/incomplete?). And I always try to
stick to saying "remote tracking branch" and not just "tracking branch"
(as the glossary does) to avoid confusion as best as I can. But that
feels quite suboptimal.
So, is there some term that describes a local branch that has been
configured for "git pull"?
Thanks,
Björn
^ permalink raw reply
* Re: [PATCH] Implement git remote mv
From: Brandon Casey @ 2008-10-22 16:52 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1224634994-1664-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna wrote:
> +static int mv(int argc, const char **argv)
> +{
> + struct option options[] = {
> + OPT_END()
> + };
> + struct remote *oldremote, *newremote;
> + struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
> + struct string_list remote_branches = { NULL, 0, 0, 0 };
> + struct rename_info rename = { argv[1], argv[2], &remote_branches };
I think some non-c99 compilers would have issues with this run-time
initialization from function arguments. Plus, what if argv doesn't have
3 elements? I see you have a check for that below...
> + int i;
> +
> + if (argc != 3)
> + usage_with_options(builtin_remote_usage, options);
-brandon
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Johannes Schindelin @ 2008-10-22 17:04 UTC (permalink / raw)
To: Jeff King; +Cc: Jakub Narebski, Ingo Molnar, git
In-Reply-To: <20081022132148.GA17393@coredump.intra.peff.net>
Hi,
On Wed, 22 Oct 2008, Jeff King wrote:
> On Wed, Oct 22, 2008 at 03:50:52AM -0700, Jakub Narebski wrote:
>
> > About printing either forward (git-describe, e.g.
> > v1.6.0.2-590-g67f6062) or backward (git-name-rev, e.g.
> > tags/v1.6.0-rc2~8): you can use git-name-rev in filter mode (git log
> > ... | git name-rev --stdin), or "git log --decorate", or '%d' in
> > --pretty format specifier (this is very new thing).
>
> The "--decorate" and "%d" code just decorates branch _tips_. My
> impression is that he wanted to see the branch mentioned even if the
> commit was not at the tip. It would be possible to extend this to print
> name-rev output, but it would be computationally and memory-intensive, I
> suspect.
FWIW I tried to do this "on-the-fly", but that did not bode well with
things like
git log --decorate=any --no-walk master $(git rev-parse master~10)
If you're interested in code:
http://thread.gmane.org/gmane.comp.version-control.git/52123/focus=52126
Ciao,
Dscho
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Johannes Schindelin @ 2008-10-22 17:41 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next,
Junio C Hamano, git
In-Reply-To: <20081022083139.GA4369@elte.hu>
Hi,
On Wed, 22 Oct 2008, Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > On Wed, 22 Oct 2008 09:29:23 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > > I've Cc:-ed Junio and the Git list as a general FYI - but it must be
> > > frustrating to get such a bugreport, because i have no reproducer.
> > >
> > > git-rerere sometimes seems to be picking up the wrong resolution. VERY
> > > rarely.
> > >
> > > It seems random and content dependent. Once it happened to
> > > arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170
> > > successful resolutions i have in my tree right now. And i do many
> > > conflict resolutions every day - and it happened only once every 6
> > > months or so.
> > >
> > > (the arch/x86/kernel/traps_32.c one happened regularly, that's why i
> > > thought it's content sha1 dependent, and not some corruption.)
> > >
> > > Next time it happens i'll be on the watchout and will save the complete
> > > tree.
> >
> > I think rerere matches preimages on the SHA1 of the conflict (or its
> > reverse), so sufficiently similar pieces of code will match. I would
> > expect things like ext2/3/4 to be candidates. Did the traps_32.c one
> > match one for traps_64.c?
> >
> > I may be mistaken, but I once followed the code in rerere to try to
> > figure out how to fix a resolution.
>
> the traps_32.c one was that git-rerere put in a traps_64.c end result.
> So i ended up with a 32-bit kernel that tried to build a 64-bit piece of
> code - fireworks. That condition persisted - i had to fix it up manually
> all the time i integrated that portion of the tree. That too was i think
> centered around a header file chunk - perhaps the #include section of
> traps_32.c and traps_64.c was similar enough in that section?
I think it might be in order to explain how git-rerere works internally:
- in case of a conflicts, the files' conflicts are written into the
rr-cache _per file_.
First, the human readable stuff after the "<<<", "|||" and ">>>" lines
is removed.
Then, the "||| ... ===" part is removed, too (in effect turning the
diff3-style conflicts into an RCS merge-style conflicts).
The result is recorded as "preimage". The conflict is identified by the
SHA-1 of _just_ the conflicts (including the "<<<", "===" and ">>>"
lines).
After all the conflicted files have been handled, a list is written to
the file "MERGE_RR" containing the SHA-1s of the conflicts together with
the file names.
- when committing, the files whose conflicts were resolved are recorded
verbatim in the file "postimage".
Now, when rerere is called again and there are conflicted files, again the
files' conflicts are identified by their SHA-1. If a resolution exists, a
3-way merge is performed with the recorded preimage (the
original file with conflict lines) as base, the postimage (the originally
resolved file) and the current file with conflict lines.
The idea being: the diff between the recorded preimage and postimage gives
the resolution that you want, and the diff between the recorded preimage
and the current file with conflict lines gives you the changes that
happened to the file in-between.
So I think that you might hit the unfortunate case where two files
happened to have the same conflicts, but you needed to resolve them one
way for one file, and another way for the other file.
Ciao,
Dscho
^ 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