* Re: gitweb - bare repos integration - owner info in description file
From: Eugene Sajine @ 2009-10-11 1:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Johannes Schindelin
In-Reply-To: <200910102045.13374.jnareb@gmail.com>
>
> The project description, project owner and (clone) url are used by
> gitweb only, so I don't see why git-clone has to feature-creep to
> set them.
>
Well my logic is simple. Gitweb is a part of git bundle. If you don't
want to use gitweb you're free to use git clone as you want. I don't
see why not to provide some usability features to it. For me it is
quite obvious that it will be more comfortable to setup gitweb if this
would be in place. Instead of putting info in few different places
manually, why not to give people a possibilty to do that using one
command?
This is usability feature, but i feel that for me as a person who will
support big ceantral bare repo hosting server, this would save huge
time and efforts...
Thanks,
Eugene
^ permalink raw reply
* Re: combine git repo historically
From: Christian Couder @ 2009-10-11 2:36 UTC (permalink / raw)
To: bill lam; +Cc: Johannes Sixt, git, Christian Couder
In-Reply-To: <20091010140358.GA3924@debian.b2j>
On Saturday 10 October 2009, bill lam wrote:
> On Fri, 09 Oct 2009, Johannes Sixt wrote:
> > bill lam schrieb:
> > > I have two git repos, no branches.
> > >
> > > repo 1.
> > > emptyrootcommit -- A ... M
> > >
> > > repo 2.
> > > emptyrootcommit -- N ... Z
> > >
> > > N was evolved from M but the time gap is large, how can I combine
> > > them into one repo
> > >
> > > emptyrootcommit -- A ... M -- N ... Z
> > >
> > > so that snapshots N .. Z will not be changed.
> >
> > $ echo $(git rev-parse N) $(git rev-parse M) >> .git/info/grafts
> > $ git filter-branch --tag-name-filter cat -- --all --not M
> >
> > i.e. you graft the older history right before the younger history, then
> > you use git filter-branch to rewrite the parentship of the younger
> > commits.
>
> Thanks, graft is new to me. I tested it works but it needs first issue
> git fetch /path/to/repo1
> within repo2 to fetch tip M from repo1 into repo2, is it correct?
>
> If I also want to fetch also all objects from repo1, what will the
> command to do it.
Maybe you should do something like:
$ git remote add repo1 /path/to/repo1
$ git fetch repo1
The fetch command should output something like:
remote: Counting objects: 423, done.
remote: Compressing objects: 100% (149/149), done.
remote: Total 363 (delta 276), reused 298 (delta 213)
Receiving objects: 100% (363/363), 136.65 KiB, done.
Resolving deltas: 100% (276/276), completed with 29 local objects.
From /path/to/repo1
* [new branch] branch1 -> repo1/branch1
* [new branch] branch2 -> repo1/branch2
So the branches in repo1 will be available in repo2 as remote/repo1/branch1,
remote/repo1/branch2, ...
> Christian Couder also mentioned the git-replace command, how to stitch
> with it?
First you need to create a commit that will replace commit N, let's call it
N' and after that you can use "git replace N N'". So the complex part is to
create N'.
You want N' to have the same content as N but to have M as parent. So you
could do something like the following:
(We suppose that commits A to M are in branch1 and that you are in the root
directory of your repo2 working directory.)
$ git checkout -b repo1-branch1 remote/repo1/branch1
$ git checkout N -- .
$ export GIT_AUTHOR_NAME=<author name of commit N>
$ export GIT_AUTHOR_EMAIL=<author email of commit N>
$ export GIT_AUTHOR_DATE=<date of commit N>
$ git commit -a
And then use the commit message from commit N, and maybe also say in the
commit message that it is replacement commit made to link repo1 with repo2
or something like that.
At this step you have created N' and you should make sure that it is exactly
what you want. It should point to the same tree as N, it should have M as
parent, ...
If everything is ok then you can use:
$ git replace N HEAD
And you should be done.
Regards,
Christian.
^ permalink raw reply
* meaning of HEAD in context of filter-branch
From: bill lam @ 2009-10-11 2:43 UTC (permalink / raw)
To: git
I tried to process some files that changed between each commit using
the command
git filter-branch --tree-filter 'git diff --name-only HEAD^.. | foo
however it seems that HEAD is fixed to mean the HEAD of the current
tip before starting git-filter-branch, by trying like this
$ git rev-list -1 HEAD^
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
git filter-branch --tree-filter 'git rev-list -1 HEAD^ >>/tmp/sha' -- --all
$ cat /tmp/sha
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
how to get the HEAD during filter-branch or other workaround?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: combine git repo historically
From: bill lam @ 2009-10-11 4:06 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Sixt, git
In-Reply-To: <200910110436.52653.chriscool@tuxfamily.org>
On Sun, 11 Oct 2009, Christian Couder wrote:
> $ git checkout -b repo1-branch1 remote/repo1/branch1
> $ git checkout N -- .
> ...
> If everything is ok then you can use:
>
> $ git replace N HEAD
Thanks for detail instruction, I tested it ok except that when trying
to checkout it reported an error
$ git checkout -b repo1-branch1 remote/oldjproject/master
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'remote/oldjproject/master' which can not
be resolved as commit?
but it ran ok by omitting that 'remote/'
$ git checkout -b repo1-branch1 oldjproject/master
Does it need to purge the file system tree before
git checkout N -- .
so that there will be no artifact leaved by M?
I found that it is necessary to do a
git reset --hard (original HEAD)
to complete the story. Is it correct?
git version 1.6.5.rc3.35.g3340
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: git-svn very slow on fetch (shared git-svn repo)
From: Eric Wong @ 2009-10-11 7:01 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <4AD04F95.7050603@obry.net>
Pascal Obry <pascal@obry.net> wrote:
> Here is the problem.
>
> Doing a:
>
> $ git svn fetch
>
> Takes age to update the repository. The long story is that I'm trying to
> have shared git-svn repositories.
>
> I'm cloning the repository on a server using a standard "git svn clone".
> I then let users cloning this repository using the procedure described
> in git-svn help. Copy/paste here:
>
> <<
> # Do the initial import on a server
> ssh server "cd /pub && git svn clone
> http://svn.example.com/project
> # Clone locally - make sure the refs/remotes/ space matches the
> server
> mkdir project
> cd project
> git init
> git remote add origin server:/pub/project
> git config --add remote.origin.fetch
> '+refs/remotes/*:refs/remotes/*'
> git fetch
> # Create a local branch from one of the branches just fetched
> git checkout -b master FETCH_HEAD
> # Initialize 'git svn' locally (be sure to use the same URL and
> -T/-b/-t options as were used on server)
> git svn init http://svn.example.com/project
> # Pull the latest changes from Subversion
> git svn rebase
> >>
>
> If you do a "git svn fetch" (to get new branches) it takes age if you
> have imported branches that are not used since a long time.
>
> I've traced this down to the Perl fetch_all procedure. It seems that the
> fetch is looking at the older version in all branches and then read the
> remote repository starting from this revision. As some branches are
> unused since a very long it it re-read most of the history. In my
> example it start at rev 8200 whereas the last revision on trunk is
> 150000 (I put trace in git-svn Perl script).
>
> I have observed that this happen only the first time.
>
> This can be confirmed by the fact that if you break git-svn fetch
> process and restart it it will start to a later revision. So it seems
> that git-svn is keeping some kind of data about what has already been
> fetched but those data are not properly copied by the procedure above.
>
> Is there a workaround that? Where are those data stored?
Hi Pascal,
For globs (branches and tags) the $GIT_DIR/svn/.metadata
config file, under the svn-remote.svn.{branches,tags}-maxRev keys.
For explicitly specified refs (e.g. "trunk"), then it's in the last
record of the corresponding rev_map (e.g.
$GIT_DIR/svn/trunk/.rev_map.$UUID) as a 4-byte revision number + 20
bytes of zeroes.
--
Eric Wong
^ permalink raw reply
* Re: git svn with non-standard svn layout
From: Eric Wong @ 2009-10-11 7:09 UTC (permalink / raw)
To: Fabian Molder; +Cc: git
In-Reply-To: <loom.20091010T001433-536@post.gmane.org>
Fabian Molder <fm122@arcor.de> wrote:
> Hello,
>
> - want to use git inside an huge SVN project
> --> so git-svn could do the job ..
>
>
> - I struggle with two things:
> A) - the SVN project has an non-standard layout
> B) - want to have (several) git's for just the (few) peaces I work on
>
> for A)
> ======
> - svn layout looks like this (simplified):
> - trunk (not really used, all interesting work in branches)
> - branches
> - r1.2
> - development
> - integration
> - r1.3
> - development
> - integration
> ...
>
> - inside development and integration is:
> - xapplication1
> - xapplication2
> - xapplication3
> ...
> - aa
> -bb
> -cc
> - zapplication1
> - zapplication2
> - zapplication3
> ...
>
> - I created an simplified svn test (from scratch; import/repo/workdir)
> via this bash-script: http://pastebin.ca/1608231
>
> for B)
> ======
> - the svn repo is very huge, but I'm only interested in these dirs:
> xapplication2/
> aa/bb/cc/zapplication1
> - my objectives:
> - have several local git's, just the ones I need:
> --> xapplication2/.git
> --> aa/bb/cc/zapplication1/.git
Hi Fabian,
Since you don't want to track the entire repo and these seem like
unrelated (history-wise) trees, you probably want the simplest cases:
git svn clone svn://example.com/path/to/xapplication2
git svn clone svn://example.com/path/to/aa/bb/cc/xapplication1
These commands are like doing the following with plain old svn:
svn co svn://example.com/path/to/xapplication2
svn co svn://example.com/path/to/aa/bb/cc/xapplication1
> I tried to use "git config svn-remote.svn.branches" to do this,
> please see in function "do_git_svn" in bash-script - but no success
svn-remote.svn.branches and tags are really only for repos with
standard layouts.
--
Eric Wong
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.5
From: Junio C Hamano @ 2009-10-11 8:40 UTC (permalink / raw)
To: git
The latest feature release GIT 1.6.5 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5-1.fc9.$arch.rpm (RPM)
This cycle took a bit longer than I hoped, but here it is. We already
have some new features cooking in 'next', and I expect we may be able to
have 1.6.6 by the end of the year.
Enjoy.
----------------------------------------------------------------
GIT v1.6.5 Release Notes
========================
In git 1.7.0, which was planned to be the release after 1.6.5, "git
push" into a branch that is currently checked out will be refused by
default.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyCurrentBranch in the receiving
repository.
Also, "git push $there :$killed" to delete the branch $killed in a remote
repository $there, when $killed branch is the current branch pointed at by
its HEAD, will be refused by default.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyDeleteCurrent in the receiving
repository.
To ease the transition plan, the receiving repository of such a
push running this release will issue a big warning when the
configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
for more details on the reason why this change is needed and the
transition plan.
Updates since v1.6.4
--------------------
(subsystems)
* various updates to gitk, git-svn and gitweb.
(portability)
* more improvements on mingw port.
* mingw will also give FRSX as the default value for the LESS
environment variable when the user does not have one.
* initial support to compile git on Windows with MSVC.
(performance)
* On major platforms, the system can be compiled to use with Linus's
block-sha1 implementation of the SHA-1 hash algorithm, which
outperforms the default fallback implementation we borrowed from
Mozilla.
* Unnecessary inefficiency in deepening of a shallow repository has
been removed.
* "git clone" does not grab objects that it does not need (i.e.
referenced only from refs outside refs/heads and refs/tags
hierarchy) anymore.
* The "git" main binary used to link with libcurl, which then dragged
in a large number of external libraries. When using basic plumbing
commands in scripts, this unnecessarily slowed things down. We now
implement http/https/ftp transfer as a separate executable as we
used to.
* "git clone" run locally hardlinks or copies the files in .git/ to
newly created repository. It used to give new mtime to copied files,
but this delayed garbage collection to trigger unnecessarily in the
cloned repository. We now preserve mtime for these files to avoid
this issue.
(usability, bells and whistles)
* Human writable date format to various options, e.g. --since=yesterday,
master@{2000.09.17}, are taught to infer some omitted input properly.
* A few programs gave verbose "advice" messages to help uninitiated
people when issuing error messages. An infrastructure to allow
users to squelch them has been introduced, and a few such messages
can be silenced now.
* refs/replace/ hierarchy is designed to be usable as a replacement
of the "grafts" mechanism, with the added advantage that it can be
transferred across repositories.
* "git am" learned to optionally ignore whitespace differences.
* "git am" handles input e-mail files that has CRLF line endings sensibly.
* "git am" learned "--scissors" option to allow you to discard early part
of an incoming e-mail.
* "git archive -o output.zip" works without being told what format to
use with an explicit "--format=zip".option.
* "git checkout", "git reset" and "git stash" learned to pick and
choose to use selected changes you made, similar to "git add -p".
* "git clone" learned a "-b" option to pick a HEAD to check out
different from the remote's default branch.
* "git clone" learned --recursive option.
* "git clone" from a local repository on a different filesystem used to
copy individual object files without preserving the old timestamp, giving
them extra lifetime in the new repository until they gc'ed.
* "git commit --dry-run $args" is a new recommended way to ask "what would
happen if I try to commit with these arguments."
* "git commit --dry-run" and "git status" shows conflicted paths in a
separate section to make them easier to spot during a merge.
* "git cvsimport" now supports password-protected pserver access even
when the password is not taken from ~/.cvspass file.
* "git fast-export" learned --no-data option that can be useful when
reordering commits and trees without touching the contents of
blobs.
* "git fast-import" has a pair of new front-end in contrib/ area.
* "git init" learned to mkdir/chdir into a directory when given an
extra argument (i.e. "git init this").
* "git instaweb" optionally can use mongoose as the web server.
* "git log --decorate" can optionally be told with --decorate=full to
give the reference name in full.
* "git merge" issued an unnecessarily scary message when it detected
that the merge may have to touch the path that the user has local
uncommitted changes to. The message has been reworded to make it
clear that the command aborted, without doing any harm.
* "git push" can be told to be --quiet.
* "git push" pays attention to url.$base.pushInsteadOf and uses a URL
that is derived from the URL used for fetching.
* informational output from "git reset" that lists the locally modified
paths is made consistent with that of "git checkout $another_branch".
* "git submodule" learned to give submodule name to scripts run with
"foreach" subcommand.
* various subcommands to "git submodule" learned --recursive option.
* "git submodule summary" learned --files option to compare the work
tree vs the commit bound at submodule path, instead of comparing
the index.
* "git upload-pack", which is the server side support for "git clone" and
"git fetch", can call a new post-upload-pack hook for statistics purposes.
(developers)
* With GIT_TEST_OPTS="--root=/p/a/t/h", tests can be run outside the
source directory; using tmpfs may give faster turnaround.
* With NO_PERL_MAKEMAKER set, DESTDIR= is now honoured, so you can
build for one location, and install into another location to tar it
up.
Fixes since v1.6.4
------------------
All of the fixes in v1.6.4.X maintenance series are included in this
release, unless otherwise noted.
^ permalink raw reply
* Re: combine git repo historically
From: Jakub Narebski @ 2009-10-11 8:48 UTC (permalink / raw)
To: Christian Couder; +Cc: bill lam, Johannes Sixt, git, Christian Couder
In-Reply-To: <200910110436.52653.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> On Saturday 10 October 2009, bill lam wrote:
> > Christian Couder also mentioned the git-replace command, how to stitch
> > with it?
>
> First you need to create a commit that will replace commit N, let's call it
> N' and after that you can use "git replace N N'". So the complex part is to
> create N'.
>
> You want N' to have the same content as N but to have M as parent. So you
> could do something like the following:
>
> (We suppose that commits A to M are in branch1 and that you are in the root
> directory of your repo2 working directory.)
>
> $ git checkout -b repo1-branch1 remote/repo1/branch1
> $ git checkout N -- .
> $ export GIT_AUTHOR_NAME=<author name of commit N>
> $ export GIT_AUTHOR_EMAIL=<author email of commit N>
> $ export GIT_AUTHOR_DATE=<date of commit N>
> $ git commit -a
>
> And then use the commit message from commit N, and maybe also say in the
> commit message that it is replacement commit made to link repo1 with repo2
> or something like that.
I think simpler solution would be to use plumbing for that. First
save commit to be replaced in a (text) file:
$ git cat-file commit N > COMMIT_N
If you want to edit only commit message and perhaps parentage (like I
think in this case), you need to simply edit COMMIT_N file, and modify
(or add) 'parent' header(s), which is between 'tree' and 'author'
header.
Then put modified commit in repository object database
$ git hash-object -t commit -w COMMIT_N
> At this step you have created N' and you should make sure that it is exactly
> what you want. It should point to the same tree as N, it should have M as
> parent, ...
>
> If everything is ok then you can use:
>
> $ git replace N HEAD
And then do
$ git replace N NEW_N
where N is _SHA-1_ of original comit ("git rev-parse --verify N^0"),
and NEW_N is SHA-1 of replacement commit, as written by git-hash-object.
> And you should be done.
But I haven't tested this. YMMV.
See also my answer here:
http://stackoverflow.com/questions/1220557/how-do-i-prepend-history-to-a-git-repo/1547490#1547490
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn very slow on fetch (shared git-svn repo)
From: Pascal Obry @ 2009-10-11 9:00 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20091011070136.GB16264@dcvr.yhbt.net>
Hi Eric,
> For globs (branches and tags) the $GIT_DIR/svn/.metadata
> config file, under the svn-remote.svn.{branches,tags}-maxRev keys.
Right. I found out that copying the .metadata solve this problem.
> For explicitly specified refs (e.g. "trunk"), then it's in the last
> record of the corresponding rev_map (e.g.
> $GIT_DIR/svn/trunk/.rev_map.$UUID) as a 4-byte revision number + 20
> bytes of zeroes.
Seems like we do not need to copy this one as it is reconstructed by a
simple rebase on the trunk branch. This is quite fast as reconstructed
from the embedded git-svn-id if I'm not mistaken.
So you confirm that copying the .metadata is the solution?
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: git-svn very slow on fetch (shared git-svn repo)
From: Eric Wong @ 2009-10-11 9:03 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <4AD19E9F.8010302@obry.net>
Pascal Obry <pascal@obry.net> wrote:
> Hi Eric,
>
>> For globs (branches and tags) the $GIT_DIR/svn/.metadata
>> config file, under the svn-remote.svn.{branches,tags}-maxRev keys.
>
> Right. I found out that copying the .metadata solve this problem.
>
>> For explicitly specified refs (e.g. "trunk"), then it's in the last
>> record of the corresponding rev_map (e.g.
>> $GIT_DIR/svn/trunk/.rev_map.$UUID) as a 4-byte revision number + 20
>> bytes of zeroes.
>
> Seems like we do not need to copy this one as it is reconstructed by a
> simple rebase on the trunk branch. This is quite fast as reconstructed
> from the embedded git-svn-id if I'm not mistaken.
>
> So you confirm that copying the .metadata is the solution?
Yes, copying .metadata should be enough. The .rev_map rebuild should
be fast.
--
Eric Wong
^ permalink raw reply
* Re: combine git repo historically
From: Andreas Schwab @ 2009-10-11 9:34 UTC (permalink / raw)
To: Christian Couder; +Cc: bill lam, Johannes Sixt, git, Christian Couder
In-Reply-To: <200910110436.52653.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> You want N' to have the same content as N but to have M as parent. So you
> could do something like the following:
>
> (We suppose that commits A to M are in branch1 and that you are in the root
> directory of your repo2 working directory.)
>
> $ git checkout -b repo1-branch1 remote/repo1/branch1
> $ git checkout N -- .
> $ export GIT_AUTHOR_NAME=<author name of commit N>
> $ export GIT_AUTHOR_EMAIL=<author email of commit N>
> $ export GIT_AUTHOR_DATE=<date of commit N>
> $ git commit -a
Isn't that what git cherry-pick does?
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: git-svn very slow on fetch (shared git-svn repo)
From: Pascal Obry @ 2009-10-11 9:37 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20091011090338.GA27480@dcvr.yhbt.net>
Eric,
> Yes, copying .metadata should be enough.
I've put this in place. Works fine.
> The .rev_map rebuild should be fast.
Yep. Thanks for your quick reply.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: meaning of HEAD in context of filter-branch
From: Andreas Schwab @ 2009-10-11 9:38 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091011024357.GA9021@debian.b2j>
bill lam <cbill.lam@gmail.com> writes:
> how to get the HEAD during filter-branch or other workaround?
>From git-filter-index(1):
Filters
The filters are applied in the order as listed below. The <command>
argument is always evaluated in the shell context using the eval
command (with the notable exception of the commit filter, for technical
reasons). Prior to that, the $GIT_COMMIT environment variable will be
^^^^^^^^^^^
set to contain the id of the commit being rewritten.
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: combine git repo historically
From: Christian Couder @ 2009-10-11 10:11 UTC (permalink / raw)
To: bill lam; +Cc: Johannes Sixt, git
In-Reply-To: <20091011040659.GB9021@debian.b2j>
On Sunday 11 October 2009, bill lam wrote:
> On Sun, 11 Oct 2009, Christian Couder wrote:
> > $ git checkout -b repo1-branch1 remote/repo1/branch1
> > $ git checkout N -- .
> > ...
> > If everything is ok then you can use:
> >
> > $ git replace N HEAD
>
> Thanks for detail instruction, I tested it ok except that when trying
> to checkout it reported an error
>
> $ git checkout -b repo1-branch1 remote/oldjproject/master
> fatal: git checkout: updating paths is incompatible with switching
> branches. Did you intend to checkout 'remote/oldjproject/master' which
> can not be resolved as commit?
>
> but it ran ok by omitting that 'remote/'
> $ git checkout -b repo1-branch1 oldjproject/master
>
> Does it need to purge the file system tree before
> git checkout N -- .
>
> so that there will be no artifact leaved by M?
Yeah, perhaps, I forgot that there could be some files added and other files
removed between M and N.
If you remove everything (except the .git directory of course), then doing:
$ git checkout N -- .
$ git add .
$ export GIT_AUTHOR_NAME=<author name of commit N>
$ export GIT_AUTHOR_EMAIL=<author email of commit N>
$ export GIT_AUTHOR_DATE=<date of commit N>
$ git commit
should do the trick if I am not missing something which may very well be the
case.
So perhaps it is easier to use Jakub's suggestion instead.
> I found that it is necessary to do a
> git reset --hard (original HEAD)
>
> to complete the story. Is it correct?
Yes, you should go back to your orginal branch at the end.
Regards,
Christian.
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Jakub Narebski @ 2009-10-11 10:39 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910101845h43a607f0sd4184da302a19963@mail.gmail.com>
On Sun, 11 Oct 2009, Eugene Sajine wrote:
> >
> > The project description, project owner and (clone) url are used by
> > gitweb only, so I don't see why git-clone has to feature-creep to
> > set them.
>
> Well my logic is simple. Gitweb is a part of git bundle. If you don't
> want to use gitweb you're free to use git clone as you want. I don't
> see why not to provide some usability features to it. For me it is
> quite obvious that it will be more comfortable to setup gitweb if this
> would be in place. Instead of putting info in few different places
> manually, why not to give people a possibilty to do that using one
> command?
>
> This is usability feature, but i feel that for me as a person who will
> support big ceantral bare repo hosting server, this would save huge
> time and efforts...
And this would be best left for a custom script creating repositories
and their git hosting related configuration. Such script of necessity
would have to be site-specific, or at least contain site-specific
configuration, like:
* whether to use gitweb.owner or filesystem uid + GECOS is enough
* whether to use gitweb.description or description file
* whether to use gitweb.url, cloneurl file, or let gitweb autogenerate
clone / fetch URL from base URL
* gitosis / gitlite configuration, if needed, or setup of public keys
for SSH authentication
* project README.html file, if used
etc.
git-clone is not a dumping ground (also, code speak louder than words).
I even think it might be mistake to have default 'description' file in
templates...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] disallow refs containing successive slashes
From: Jens Lehmann @ 2009-10-11 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vws327wbp.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> When creating branches using names starting with '/' or containing a '//',
>> a leading slash would just vanish and successive slashes were 'compressed'
>> into just one slash.
>
> Hmm. We already do that without your patch.
>
> $ git branch /foo//bar
> $ git for-each-ref --format='%(refname)'
> refs/heads/foo/bar
> refs/heads/master
> $ git branch -d /foo//bar
> Deleted branch /foo//bar (was deadbeef)
> $ git for-each-ref --format='%(refname)'
> refs/heads/master
Yes, but git changes the name silently from '/foo//bar' to 'foo/bar'!
The automagical removal of some slashes leads to strange behaviour when
using such names:
$ git checkout -b foo/bar
Switched to a new branch 'foo/bar'
$ git checkout -b /foo//bar
fatal: A branch named '/foo//bar' already exists.
$ git for-each-ref --format='%(refname)'
refs/heads/foo/bar
refs/heads/master
git claims wrongly that "A branch named '/foo//bar' already exists.".
And that same happens to tag and repo names, leading to other strange
effects:
$ git tag /foo//bar
$ git tag
foo/bar
That is not the tagname the user provided.
$ git remote add /foo//bar git://git.kernel.org/pub/scm/git/git.git
$ git remote show
warning: Config remote shorthand cannot begin with '/': /foo//bar.url
warning: Config remote shorthand cannot begin with '/': /foo//bar.fetch
$ git fetch /foo//bar
warning: Config remote shorthand cannot begin with '/': /foo//bar.url
warning: Config remote shorthand cannot begin with '/': /foo//bar.fetch
fatal: 'foo/bar' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
Note: git fetch uses both versions of the remote name in its output.
>> I became aware of this issue while looking into problems occuring
>> when a user created a branch starting with a '/' in git gui (e.g.
>> "/foo"). Strange things happen, while git gui shows the current
>> branch as "/foo" under the hood a branch "foo" (without the slash)
>> had been created. But then you can't delete "/foo" from git gui,
>> because a branch of that name doesn't exist.
>
> Perhaps an interface to give a cleaned-up version, e.g.
>
> $ git check-ref-format --print refs/heads//foo/bar
> refs/heads/foo/bar
>
> is what you want in order to fix git-gui? I dunno.
Yes, one solution could be to fix every application handling branch, tag
or repo names to mimic the namechange done in the bowels of git. But i
think it is not worth the hassle. Every application i tested (git gui,
gitk and a handful of git commands) just assumes - and i think rightfully
so - that refnames will not change while they are being created (And they
do call "git check-ref-format" or strbuf_check_branch_ref() and friends
to make sure they have a valid refname, but it gets changed nonetheless).
With this patch you get an error every time you try to create such a
refname in the first place and the strange effects and the ambiguity
of refnames ('/foo//bar' is a synonym for 'foo/bar' right now) just
go away.
The motivation for this patch was a confused user at my dayjob. IMHO
most people don't use '/foo//bar' on purpose but the extra slashes get
there through typos, copy & paste errors and such. Then generating an
error might just be the Right Thing to do to avoid the problems with
the changed refname afterwards.
^ permalink raw reply
* Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Matt McClure @ 2009-10-11 11:40 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Shawn O. Pearce, vcs-fast-import-devs, git, Johannes Schindelin
In-Reply-To: <fabb9a1e0910081058m59527600o392a6b438b18512e@mail.gmail.com>
On Thu, Oct 8, 2009 at 1:58 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Other options that are clearly git should be declared as:
>>
>> option git max-pack-size=2048
>>
>> with the meaning of option being declared something like:
>>
>> If the parsing VCS name appears as the first argument, the parsing
>> VCS must recognize and support the supplied option, and if not
>> recognized or not supported must abort parsing altogether.
>>
>> If the parsing VCS name is not the first argument, it must entirely
>> ignore the option command and not try to process its contents.
>
> I think it makes to ignore options that are not for our vcs, as long
> as options that change import behavior (such as marks, date-format)
> are combined with, say, 'feature tool=git'. This way we can be sure
> that when outputting out a vcs specific stream, it is only parsed by
> that vcs.
I prefer option-scope VCS specifiers over stream-scope specifiers.
The latter would artificially reduce interoperability between VCSs.
Who is the fast-output developer to say that only one fast-import tool
should use his stream?
--
Matt
http://www.google.com/profiles/matthewlmcclure
^ permalink raw reply
* Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Sverre Rabbelier @ 2009-10-11 11:58 UTC (permalink / raw)
To: Matt McClure
Cc: Shawn O. Pearce, vcs-fast-import-devs, git, Johannes Schindelin
In-Reply-To: <e48c5e540910110440k33e3d0dcp6d8c1480b5848366@mail.gmail.com>
Heya,
On Sun, Oct 11, 2009 at 13:40, Matt McClure <mlm@aya.yale.edu> wrote:
> Who is the fast-output developer to say that only one fast-import tool
> should use his stream?
He knows that a foreign tool that does not heed his 'option git
stream-changing-option' will mis-parse the stream. For example the
Bazaar people were talking about adding some Bazaar-specific options
so facilitate bzr-bzr traffic, it would be impossible for a non-bzr
importer to properly understand the stream if they were to ignore the
bzr-specific options. So either options should only affect things that
do not change semantics (such as perhaps whether or not to be quiet,
whether to try and limit memory usage, etc), or it should be possible
to indicate that an option is changes semantic and cannot be ignored.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Installing full fledged git on solaris?
From: Dilip M @ 2009-10-11 12:26 UTC (permalink / raw)
To: git
Hello,
Has anyone has the list of pkg's to be installed on solaris 10 sparc,
to get the GIT compiled (with all features)..
thanks in advance for sharing...
--
Dilip
^ permalink raw reply
* Re: Installing full fledged git on solaris?
From: Dilip M @ 2009-10-11 12:57 UTC (permalink / raw)
To: git
In-Reply-To: <c94f8e120910110526r68e4abe1l269dc4b3ab22bac3@mail.gmail.com>
On Sun, Oct 11, 2009 at 5:56 PM, Dilip M <dilipm79@gmail.com> wrote:
> Hello,
>
>
> Has anyone has the list of pkg's to be installed on solaris 10 sparc,
> to get the GIT compiled (with all features)..
>
> thanks in advance for sharing...
Trying to compile the latest version exit with this error
CC xdiff/xpatience.o
AR xdiff/lib.a
LINK git-fast-import
Undefined first referenced
symbol in file
libiconv_close libgit.a(utf8.o)
libiconv_open libgit.a(utf8.o)
libiconv libgit.a(utf8.o)
ld: fatal: Symbol referencing errors. No output written to git-fast-import
collect2: ld returned 1 exit status
gmake: *** [git-fast-import] Error 1
--
Dilip
^ permalink raw reply
* Re: Installing full fledged git on solaris?
From: Ben Walton @ 2009-10-11 13:12 UTC (permalink / raw)
To: Dilip M; +Cc: git
In-Reply-To: <c94f8e120910110526r68e4abe1l269dc4b3ab22bac3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
Excerpts from Dilip M's message of Sun Oct 11 08:26:10 -0400 2009:
Hi Dilip,
> Has anyone has the list of pkg's to be installed on solaris 10 sparc,
> to get the GIT compiled (with all features)..
This may not be what you want, but if you use the CSW package stack,
you can get git easily. This is, I believe, a very complete git
installation. There will soon be an update to 1.6.5.
http://www.opencsw.org/packages/git
If your intent is to build it yourself, let me know and I'll share
with you the build recipe I use, which will outline (within the CSW
stack) which packages are used for compilation and which for runtime
dependencies. You should be able to translate it to use the
libs/tools available to solaris 10 (that aren't in 8, which we also
support).
HTH
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Installing full fledged git on solaris?
From: Steven Noonan @ 2009-10-11 13:14 UTC (permalink / raw)
To: Dilip M; +Cc: git
In-Reply-To: <c94f8e120910110557q764dbf19s33c52e7f5120662@mail.gmail.com>
On Sun, Oct 11, 2009 at 5:57 AM, Dilip M <dilipm79@gmail.com> wrote:
> On Sun, Oct 11, 2009 at 5:56 PM, Dilip M <dilipm79@gmail.com> wrote:
>> Hello,
>>
>>
>> Has anyone has the list of pkg's to be installed on solaris 10 sparc,
>> to get the GIT compiled (with all features)..
>>
>> thanks in advance for sharing...
>
> Trying to compile the latest version exit with this error
>
> CC xdiff/xpatience.o
> AR xdiff/lib.a
> LINK git-fast-import
> Undefined first referenced
> symbol in file
> libiconv_close libgit.a(utf8.o)
> libiconv_open libgit.a(utf8.o)
> libiconv libgit.a(utf8.o)
> ld: fatal: Symbol referencing errors. No output written to git-fast-import
> collect2: ld returned 1 exit status
> gmake: *** [git-fast-import] Error 1
>
So try installing libiconv? (I think the package name on Solaris is
SUNWgnu-libiconv)
- Steven
^ permalink raw reply
* Re: combine git repo historically
From: Johannes Sixt @ 2009-10-11 13:07 UTC (permalink / raw)
To: Jakub Narebski, Christian Couder; +Cc: bill lam, git, Christian Couder
In-Reply-To: <m31vlagvtw.fsf@localhost.localdomain>
On Sonntag, 11. Oktober 2009, Jakub Narebski wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > $ git checkout -b repo1-branch1 remote/repo1/branch1
> > $ git checkout N -- .
> > $ export GIT_AUTHOR_NAME=<author name of commit N>
> > $ export GIT_AUTHOR_EMAIL=<author email of commit N>
> > $ export GIT_AUTHOR_DATE=<date of commit N>
> > $ git commit -a
This would not preserver the committer, but in particular the committer date
is rather important for history traversal. You really don't want to change
it. I used a much more elaborate pipleine involving git-commit-tree because I
did not think about this simple procedure:
> $ git cat-file commit N > COMMIT_N
>[ $ edit COMMIT_N ]
> $ git hash-object -t commit -w COMMIT_N
Thanks for this tip, Jakub.
Christian, one thing that worries me is that 'git cat-file commit foo' returns
the replacement (bar) instead of the original (foo). Is it intended? There is
no way to retrieve the original commit using plumbing unless the replacement
is removed. Am I right?
-- Hannes
^ permalink raw reply
* Re: Installing full fledged git on solaris?
From: Dilip M @ 2009-10-11 13:34 UTC (permalink / raw)
To: Steven Noonan; +Cc: git
In-Reply-To: <f488382f0910110614r144fa14g5c1eba2cc0cb5b8a@mail.gmail.com>
On Sun, Oct 11, 2009 at 6:44 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> On Sun, Oct 11, 2009 at 5:57 AM, Dilip M <dilipm79@gmail.com> wrote:
>> On Sun, Oct 11, 2009 at 5:56 PM, Dilip M <dilipm79@gmail.com> wrote:
>>> Hello,
>>>
>>>
>>> Has anyone has the list of pkg's to be installed on solaris 10 sparc,
>>> to get the GIT compiled (with all features)..
>>>
>>> thanks in advance for sharing...
>>
>> Trying to compile the latest version exit with this error
>>
>> CC xdiff/xpatience.o
>> AR xdiff/lib.a
>> LINK git-fast-import
>> Undefined first referenced
>> symbol in file
>> libiconv_close libgit.a(utf8.o)
>> libiconv_open libgit.a(utf8.o)
>> libiconv libgit.a(utf8.o)
>> ld: fatal: Symbol referencing errors. No output written to git-fast-import
>> collect2: ld returned 1 exit status
>> gmake: *** [git-fast-import] Error 1
>>
>
> So try installing libiconv? (I think the package name on Solaris is
> SUNWgnu-libiconv)
I already have it.
[2108]dilim@blrmimsbuild4:~/dl/tig-0.14.1> pkginfo | grep libiconv
application SMCliconv libiconv
--
Dilip
^ permalink raw reply
* Re: Installing full fledged git on solaris?
From: Dilip M @ 2009-10-11 13:38 UTC (permalink / raw)
To: Ben Walton; +Cc: git
In-Reply-To: <1255265817-sup-4123@ntdws12.chass.utoronto.ca>
On Sun, Oct 11, 2009 at 6:42 PM, Ben Walton <bwalton@artsci.utoronto.ca> wrote:
...snip...
> If your intent is to build it yourself, let me know and I'll share
> with you the build recipe I use, which will outline (within the CSW
> stack) which packages are used for compilation and which for runtime
> dependencies. You should be able to translate it to use the
> libs/tools available to solaris 10 (that aren't in 8, which we also
> support).
Please share...
--
Dilip
^ 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