* Re: .git and retrieving full source tree for own project(s)
From: Junio C Hamano @ 2009-09-04 20:04 UTC (permalink / raw)
To: armencho@gmail.com; +Cc: git
In-Reply-To: <981b72360909041252i29551a5chb8b3a2a5c6444ee3@mail.gmail.com>
"armencho@gmail.com" <armencho@gmail.com> writes:
> What I am wondering about is, what is gits identity for a repository?
> I don't share or publish the source directory anywhere, and just for
> testing I removed everything but the ".git" directory and tried "git
> checkout" and "git checkout master".
"git checkout" is a short-hand for "git checkout HEAD" which is to request
"switch to the branch denoted by HEAD, i.e. the current branch, while
keeping my local changes to the work tree and the index".
"git checkout master" is a request to "switch to the master branch, while
keeping my local changes to the work tree and the index".
In this case, your "delete everything" is your local change, and git did
its best to preserve it while switching branches.
If you want to "copy this and that files and directories out of the
commit at the tip of the current branch and deposit them in my work tree
and index", you would say
$ git checkout HEAD this that
so a request for checking everything out would be a natural extension of
the above that would be:
$ git checkout HEAD .
If you want to "copy this and that files and directories out of the index
and deposit them in my work tree", you would say
$ git checkout this that
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Daniel Barkalow @ 2009-09-04 20:10 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <fabb9a1e0909041235x74a3b9b4gf65e650ca0d00831@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2258 bytes --]
On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org> wrote:
> > Some foreign vcses, including the only one I ever personally use, do not
> > have URLs, and require a bunch of options and paths to specify a
> > repository. I don't want to have to use:
> >
> > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
>
> Btw, doesn't p4 have these config files that you can download that
> contain the configuration? In that case
> 'p4://example.org/p4/main-development.configfile' would be very
> convenient.
The only thing I know of which you might be thinking of is "client
specifications", which are like git superprojects. They're almost certain
to only specify one of the multiple locations that you want to have in the
same repository; the multiple locations are the paths you want to treat
as branches, and the client picks one branch of each project and places
it in some non-branch-specific location relative to other projects. (Of
course, someday I might want to support importing a client specification
as a git project with submodules, but it's got the same issues as
svn::externals without revision specifications seems to).
In any case, p4 doesn't have any easy generic way to specify how to
contact the server, and doesn't have anything client-side.
> Regardless, I do think there should be some way to specify all this
> outside of the url, but to me that's secondary. I think the primary
> usecase is/should be cloning from some url in the form of
> 'hg://example.org/foo', rather than 'http://example.org/some-hg-repo'
> or 'p4://.......', since those are both exceptions (the former being
> an ambiguous url, and the latter being a non-url). Now I do understand
> if you don't want to spend your time on implementing the specialized
> url support since it doesn't scratch your itch, but at least your
> series shouldn't impend supporting that in the near future.
I'm pretty sure that this series makes your primary usecase slightly
simpler to support, because it no longer is expected to handle the
ambiguous "http://" class of URLs.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: .git and retrieving full source tree for own project(s)
From: armencho @ 2009-09-04 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqfyfpdc.fsf@alter.siamese.dyndns.org>
On Fri, Sep 4, 2009 at 22:04, Junio C Hamano<gitster@pobox.com> wrote:
> In this case, your "delete everything" is your local change, and git did
> its best to preserve it while switching branches.
>
> If you want to "copy this and that files and directories out of the
> commit at the tip of the current branch and deposit them in my work tree
> and index", you would say
>
> $ git checkout HEAD this that
>
> so a request for checking everything out would be a natural extension of
> the above that would be:
>
> $ git checkout HEAD .
>
> If you want to "copy this and that files and directories out of the index
> and deposit them in my work tree", you would say
>
> $ git checkout this that
>
>
This makes sense now. I have tested this and it all functions as you
said. Thanks for your help!
^ permalink raw reply
* Strange merge failure (would be overwritten by merge / cannot merge)
From: Christoph Haas @ 2009-09-04 20:28 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear list,
I'm struggling with a pretty simple Git repository where I maintain one
of my Debian packages. It has two branches:
- upstream (contains the unaltered original software unpacked from
a .tar.gz)
- master (derived from upstream plus Debian specific changes)
Now I imported a new upstream version into the upstream branch. And then
tried to merge the 'upstream' branch into the 'master' branch to work on
it. And suddenly I get this error:
error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
Cannot merge.
So it looks like the 'cream-abbr-eng.vim' file has been altered. And it
contains some non-ASCII characters (it's a VIM script file) so perhaps
automatic merging fails. But can't I just tell Git to screw my file in
the 'master' branch and just overwrite my file? No merge strategy helped
me accomplish that.
To reproduce my problem:
$> git clone git://git.workaround.org/cream
$> cd cream
$> git merge origin/upstream
error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
Cannot merge.
fatal: merging of trees 70008c82f82a7985531aa2d039c03fdf944ea267 and
78d3a35e300434d6369424dd873bb587beacfaa4 failed
Help welcome. I'm no Git guru and totally at a loss here. As a last
resort I would start from scratch losing all of my Git history.
Kindly
Christoph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqheHQACgkQCV53xXnMZYZSaQCdF4JovwKUx1FIOq82+joGUIlq
a7UAoIoC2mm2L6Pv7MvZGzOIRNgktb2B
=pklM
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Johannes Schindelin @ 2009-09-04 21:08 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <fabb9a1e0909041235x74a3b9b4gf65e650ca0d00831@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1650 bytes --]
Hi,
On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org>
> wrote:
> > Some foreign vcses, including the only one I ever personally use, do
> > not have URLs, and require a bunch of options and paths to specify a
> > repository. I don't want to have to use:
> >
> > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
>
> Btw, doesn't p4 have these config files that you can download that
> contain the configuration? In that case
> 'p4://example.org/p4/main-development.configfile' would be very
> convenient.
If that's how p4 users initialize their working directories, then that is
the way to go.
And I cannot start to believe that the complicated way you described is
the common way to initialize p4 working directories, as that would tempt
the intelligence/enthusiasm of the average programmer.
> > For cases where the foreign vcs has something to put in the "url"
> > spot, you don't need to set "vcs". In fact, you are only allowed to
> > set one or the other of "vcs" and "url" with my current version. What
> > you're interested in is explicitly left for later, when we have a
> > prototype helper for such a foreign vcs and can try it out with
> > potential users.
>
> I need to hurry up and get working on that hg implementation then :).
Indeed you do. If only to prove that _this_ and the likes are something
to optimize for, not some obscure vcs config variable that only introduces
a little-exercized code path that's _prone_ to break and does not help
anybody.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Daniel Barkalow @ 2009-09-04 22:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0909042305390.8306@pacific.mpi-cbg.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2765 bytes --]
On Fri, 4 Sep 2009, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
>
> > On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org>
> > wrote:
> > > Some foreign vcses, including the only one I ever personally use, do
> > > not have URLs, and require a bunch of options and paths to specify a
> > > repository. I don't want to have to use:
> > >
> > > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
> >
> > Btw, doesn't p4 have these config files that you can download that
> > contain the configuration? In that case
> > 'p4://example.org/p4/main-development.configfile' would be very
> > convenient.
>
> If that's how p4 users initialize their working directories, then that is
> the way to go.
>
> And I cannot start to believe that the complicated way you described is
> the common way to initialize p4 working directories, as that would tempt
> the intelligence/enthusiasm of the average programmer.
Perforce is probably the single most popular system for git to import from
because it is such a monumental pain to use for anything at all that it's
easier to learn git, write a git importer, and use your git importer than
it is to actually use Perforce directly.
Of course, it's not really beyond the average programmer to get a p4
working directory, because whoever is running the server will have
provided a file to copy and instructions on setting an environment
variable. They don't know what the magic formula means; they just use it.
And they only work on one branch until that branch is done with,
and then they throw away that working directory, get a new working
directory, and never look at the other branch's history again (and
certainly never track anything across branches). Also, they have p4
experts who deal with merging branches so that stuff doesn't get lost when
moving to a new branch. And the experts have scripts built into the
release process that attempt to insure that things don't get lost. The
reason that my helper can't have a single location for a repository is
that the branches of a single project are strewn randomly about the
namespace, and a proper git import needs to know what to stitch into a
single repository.
For the matter of where the server is, Perforce supports just having a
"server:port" value, but if the organization uses this, there's no
authentication of users possible. Instead, organizations set up an ad hoc
collection of ssh proxies and give people a string which is the command to
go through those proxies, because Perforce only knows how to use rsh or a
command you provide that acts like rsh.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Johannes Schindelin @ 2009-09-04 22:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909041750390.28290@iabervon.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4508 bytes --]
Hi,
On Fri, 4 Sep 2009, Daniel Barkalow wrote:
> On Fri, 4 Sep 2009, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> >
> > > On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org>
> > > wrote:
> > > > Some foreign vcses, including the only one I ever personally use, do
> > > > not have URLs, and require a bunch of options and paths to specify a
> > > > repository. I don't want to have to use:
> > > >
> > > > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
> > >
> > > Btw, doesn't p4 have these config files that you can download that
> > > contain the configuration? In that case
> > > 'p4://example.org/p4/main-development.configfile' would be very
> > > convenient.
> >
> > If that's how p4 users initialize their working directories, then that is
> > the way to go.
> >
> > And I cannot start to believe that the complicated way you described is
> > the common way to initialize p4 working directories, as that would tempt
> > the intelligence/enthusiasm of the average programmer.
>
> Perforce is probably the single most popular system for git to import
> from because it is such a monumental pain to use for anything at all
> that it's easier to learn git, write a git importer, and use your git
> importer than it is to actually use Perforce directly.
>
> Of course, it's not really beyond the average programmer to get a p4
> working directory, because whoever is running the server will have >
> provided a file to copy and instructions on setting an environment
> variable.
That is what we need to optimize for, then.
> They don't know what the magic formula means; they just use it. And they
> only work on one branch until that branch is done with, and then they
> throw away that working directory, get a new working directory, and
> never look at the other branch's history again (and certainly never
> track anything across branches). Also, they have p4 experts who deal
> with merging branches so that stuff doesn't get lost when moving to a
> new branch. And the experts have scripts built into the release process
> that attempt to insure that things don't get lost. The reason that my
> helper can't have a single location for a repository is that the
> branches of a single project are strewn randomly about the namespace,
> and a proper git import needs to know what to stitch into a single
> repository.
And why not having the different branches which are strewn randomly about
the namespace as separate remotes for a Git repository? After all, the
average p4 user will be wanting to work on _one_ branch, as you so aptly
described.
> For the matter of where the server is, Perforce supports just having a
> "server:port" value, but if the organization uses this, there's no
> authentication of users possible. Instead, organizations set up an ad
> hoc collection of ssh proxies and give people a string which is the
> command to go through those proxies, because Perforce only knows how to
> use rsh or a command you provide that acts like rsh.
That explains a tiny part of the long path you provided, but certainly not
all (I am especially curious what /bin/true thinks it's doing in that
URL).
If what you said about ssh is true, then it should be the same type of
invocation everywhere, and it should certainly be very easy to provide a
shortcut for that URL; no need for the _user_ (who could not care less how
ssh happens to be called) to remember.
Something like "git clone p4::ssh://p4ssh@projects/foo/bar-1.0/..." should
become a very easy and intuitive way for the average programmer to clone a
p4 branch into a Git repository.
Should the developer ever need to work with another branch of the same
project, very easy:
$ git remote add -f bar-1.1 p4::ssh://p4ssh@projects/foo/bar-1.1/...
$ git checkout -b my-1.1 bar-1.1/master
Now, I am not married to having more than one remote for multiple
branches, but there is _no_ reason why this has to be done at clone time,
if the average p4 user does not do that either. You can always teach
git-remote-p4 to behave sensibly and ask the user to
$ git config --add remote.origin.fetch \
+/foo/bar-1.1:refs/remotes/origin/bar-1.1
Note, these are two alternative suggestions. I am not trying to decide
what is better here, but I am convinced that both options are more
intuitive than the "vcs" variable.
Ciao,
Dscho
^ permalink raw reply
* Re: [JGIT] Request for help
From: Gabe @ 2009-09-04 23:47 UTC (permalink / raw)
To: Mark Struberg; +Cc: Douglas Campos, Jonas Fonseca, git
In-Reply-To: <658028.86274.qm@web27804.mail.ukl.yahoo.com>
On Fri, Sep 4, 2009 at 10:28 AM, Mark Struberg<struberg@yahoo.de> wrote:
> Hi!
>
> Work has been done at
>
> http://github.com/sonatype/JGit/tree/mavenize
>
> Please feel free to pull/fork and share your changes! I'd be happy to pull it in.
>
> @Gabe: your patch seems to got filtered by the list, I think sharing such big things is easier by using github. Would be cool if you could help us!
Ok, I'll fork and send a patch request shortly. I was thinking about
it earlier, and I may add a couple of features that all OS projects
should follow (e.g. License in the jar, etc.).
As to a few questions that have been raised:
1) I pick the 'sources' folder because it's good metadata management.
Everything in the root folder should be about or related to managing
the project. No direct source folders, as it clutters the layout.
Best to be perfectly clear where all the action is happening. It's a
simple convention I wished more projects followed.
2) I haven't worked with the find-bugs plugin. I looked it up, but it
seems to only generate documents in the 'site'/reporting profile.
Thus it wouldn't necessarily affect the building of the software. It
would really only be useful if you had something like a Hudson CI
infrastructure or site generation going on to build a website and show
the reports. I could certainly add that, though, if you like.
3) The LICENSE file can be at the top level. Not really an issue for
me one way or another. Just a personal preference on how I have
structured all of my previous Maven projects.
-Gabe
>
> LieGrue,
> strub
>
> --- On Fri, 9/4/09, Mark Struberg <struberg@yahoo.de> wrote:
>
>> From: Mark Struberg <struberg@yahoo.de>
>> Subject: Re: [JGIT] Request for help
>> To: "Douglas Campos" <douglas@theros.info>
>> Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
>> Date: Friday, September 4, 2009, 4:49 PM
>> Hi Douglas!
>>
>> http://github.com/sonatype/JGit
>>
>> The branch will be called mavenizing or so.
>>
>> Will post this after I got the tests running.
>>
>> LieGrue,
>> strub
>>
>> --- On Fri, 9/4/09, Douglas Campos <douglas@theros.info>
>> wrote:
>>
>> > From: Douglas Campos <douglas@theros.info>
>> > Subject: Re: [JGIT] Request for help
>> > To: "Mark Struberg" <struberg@yahoo.de>
>> > Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>,
>> git@vger.kernel.org,
>> "Gabe McArthur" <gabriel.mcarthur@gmail.com>
>> > Date: Friday, September 4, 2009, 4:44 PM
>> > On Fri, Sep 4, 2009
>> > at 9:47 AM, Mark Struberg <struberg@yahoo.de>
>> > wrote:
>> >
>> >
>> > as an old saying tells us: how to climb a mountain?
>> step
>> > after step! ;)
>> >
>> >
>> >
>> > I suggest we create a fresh branch based on the
>> Shawns
>> > current version and add all the features
>> incrementally.
>> >
>> >
>> >
>> > please point out where this branch will happen, I want
>> to
>> > give some help too.
>> >
>> >
>>
>>
>>
>> --
>> 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
* Re: Strange merge failure (would be overwritten by merge / cannot merge)
From: David Aguilar @ 2009-09-04 23:45 UTC (permalink / raw)
To: Christoph Haas; +Cc: git
In-Reply-To: <4AA17874.7090905@debian.org>
On Fri, Sep 04, 2009 at 10:28:36PM +0200, Christoph Haas wrote:
>
> Now I imported a new upstream version into the upstream branch. And then
> tried to merge the 'upstream' branch into the 'master' branch to work on
> it. And suddenly I get this error:
>
> error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
> Cannot merge.
>
> To reproduce my problem:
>
> $> git clone git://git.workaround.org/cream
> $> cd cream
> $> git merge origin/upstream
> error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
> Cannot merge.
> fatal: merging of trees 70008c82f82a7985531aa2d039c03fdf944ea267 and
> 78d3a35e300434d6369424dd873bb587beacfaa4 failed
Very odd indeed!
$ git version
git version 1.6.4.2.264.g79b4f
I was able to workaround it:
$ rm *
$ git add -u
$ git merge origin/upstream
I've never run into this before.
I think it has to do with all the renamed files.
It looks like you're running into ain unfortunate edge case.
The merge-base of both branches (the initial commit) has all
files underneath a cream/ directory.
Both descendants (upstream and master) moved files up to the
root. So when you go to merge those histories the merge driver
gets confused.
What happened in master? cream/A -> A
What happened in upstream? cream/A -> A
That seems like an edge case that might need some attention.
Anyways, once you do the workaround merge it'll settle
itself out and won't happen to you again since the merge will
resolve it for all your future commits (future merges will
have a new, rename-safe merge base).
Does anyone else on the list have any insights?
--
David
^ permalink raw reply
* Re: [JGIT] Request for help
From: Douglas Campos @ 2009-09-05 0:06 UTC (permalink / raw)
To: Gabe; +Cc: Mark Struberg, Jonas Fonseca, git
In-Reply-To: <524457d10909041647u562601d5q69142eefe894ac5b@mail.gmail.com>
> Ok, I'll fork and send a patch request shortly. I was thinking about
> it earlier, and I may add a couple of features that all OS projects
> should follow (e.g. License in the jar, etc.).
Gabe, is there some task that you want to share with me? I have a
short timeframe of 4hours to invest on mavenization.
Cheers
Douglas Campos (qmx)
^ permalink raw reply
* Re: [JGIT] Request for help
From: Gabe McArthur @ 2009-09-05 1:29 UTC (permalink / raw)
To: Douglas Campos; +Cc: Mark Struberg, Jonas Fonseca, git@vger.kernel.org
In-Reply-To: <ed88cb980909041706n26e50107m2343d4d922788459@mail.gmail.com>
I'll post the pull request to github within 3-4 hours. Is that what
you mean by invest? My patch will contain everything I submitted
before plus a bit more. That patch set should contain everything
necessary to build, plus any refinements to whatever is already in the
'mavenize' branch.
-Gabe
On Sep 4, 2009, at 5:06 PM, Douglas Campos <douglas@theros.info> wrote:
>> Ok, I'll fork and send a patch request shortly. I was thinking about
>> it earlier, and I may add a couple of features that all OS projects
>> should follow (e.g. License in the jar, etc.).
>
> Gabe, is there some task that you want to share with me? I have a
> short timeframe of 4hours to invest on mavenization.
>
> Cheers
> Douglas Campos (qmx)
^ permalink raw reply
* Re: Error with git svn show-ignore: forbidden access
From: Eric Wong @ 2009-09-05 5:57 UTC (permalink / raw)
To: Yann Simon; +Cc: git
In-Reply-To: <551f769b0909010246u524599bcoc5b227f4a6279259@mail.gmail.com>
Yann Simon <yann.simon.fr@gmail.com> wrote:
> Hi,
>
> with git version 1.6.4:
>
> $ git svn show-ignore > .gitignore
> RA layer request failed: Server sent unexpected return value (403
> Forbidden) in response to PROPFIND request for
> '/repos/XXX/YYY/ZZZ/trunk/aaa' at /usr/lib/git-core/git-svn line 2243
>
> Is git svn show-ignore making request to the svn server?
Hi Yann,
Yes, git svn has to read the svn:ignore property remotely since it
doesn't do anything with it when it fetches. Do you have read
permissions to /repos/XXX/YYY/ZZZ/trunk/aaa on that repo?
> I tried also with the --no-minimize-url option but get as answer:
> $ git svn --no-minimize-url show-ignore
> Unknown option: no-minimize-url
>
> Thanks for the help
For everything besides initialization/clone, git svn reads the url in
your $GIT_CONFIG. --minimize-url is only used for the initial setup.
You can edit it to move the URL down/up a level if you edit your
corresponding fetch/branches/tags lines:
before:
[svn-remote "svn"]
url = http://example.com/
fetch = project/trunk:refs/remotes/trunk
branches = project/branches/*:refs/remotes/*
tags = project/tags/*:refs/remotes/tags/*
after:
[svn-remote "svn"]
url = http://example.com/project
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
--
Eric Wong
^ permalink raw reply
* Re: Question about git-svn
From: Eric Wong @ 2009-09-05 6:09 UTC (permalink / raw)
To: martin liste larsson; +Cc: git
In-Reply-To: <b4abed330908310601h197f8909h8f626e918f8e5090@mail.gmail.com>
martin liste larsson <martin.liste.larsson@gmail.com> wrote:
> I have a problem using git-svn. Is this the right place to ask then?
Hi, Yes, feel free to Cc me directly as well.
> I have followed Andy Delcambre's
> http://herebeforeatreplies.com/2008/03/04/git-svn-workflow.html, but
> it seems that not all my tags and branches are being imported from svn
> to (local) git. That is, 'git branch -a' gives much less output (about
> half) of the combination 'svn list http://repos/branches' and 'svn
> list http://repos/tags'.
Are there branches/tags in subdirectories?
As in, do you have stuff in http://repos/branches/foo/* as well
as just http://repos/branches/* ?
You'll need git 1.6.4 to handle that with multiple branches entries:
before:
[svn-remote "svn"]
branches = project/branches/*:refs/remotes/*
after:
[svn-remote "svn"]
branches = project/branches/*:refs/remotes/*
branches = project/branches/foo/*: refs/remotes/foo/*
> What's missing seems to be the newest
> branches and tags.
Just checking the obvious, you are running "git svn fetch", right?
--
Eric Wong
^ permalink raw reply
* Re: tracking branch for a rebase
From: Jeff King @ 2009-09-05 6:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Michael J Gruber, Pete Wyckoff, git
In-Reply-To: <20090904185949.GA21583@atjola.homenet>
On Fri, Sep 04, 2009 at 08:59:49PM +0200, Björn Steinbrink wrote:
> "git pull --rebase" is not the same as:
> "git fetch origin && git rebase origin/foo", but:
>
> git fetch origin && git rebase --onto origin/foo $reflog_merge_base
>
> Where $reflog_merge_base is the first merge base is found between the
> current branch head, and the reflog entries for origin/foo.
Thanks, I didn't know about the trick (not being, as I mentioned, a pull
--rebase user). I can see arguments for or against a rebase-default
using that feature. On one hand, it simplifies the explanation for
people going between "pull --rebase" and "fetch && rebase". And I think
it should generally Do What You Mean in the case that upstream hasn't
rebased. Are there cases you know of where it will do the wrong thing?
I don't know if people would be confused that "git rebase" does not
exactly default to "git rebase $upstream", which is at least easy to
explain.
> > The biggest question is whether it should respect branch.*.merge, or
> > just branch.*.rebase (I never use the latter simply because I never use
> > "git pull", but I think it is probably reasonable to restrict it to
> > cases where you said you are interested in rebasing in general).
>
> Hm, you'll probably want "git merge" to pickup the default as well then,
> right? And that should only do so if branch.*.rebase is not set. So
> effectively, you still have to use the right command, but can skip the
> argument. Having to deal a lot with git-svn, I also regulary use its
> "git svn rebase --local", which means "just rebase, don't fetch".
I hadn't considered whether "git merge" should get a default. To be
honest, my intended use case was not really to replace pull, but as a
shorthand for running "git rebase -i". Upstream has the published
commits, so it is a nice shortcut to say "let me munge all of the
commits that I haven't published yet".
Of course the "published" status of those commits is not guaranteed
(they might have been published in another branch, your
tracking refs might not be up to date, etc) but I think it's a good rule
of thumb.
And by automating the shorthand we reduce the chance of errors. For
example, I usually base my topic branches from origin/master. But the
other day I happened to be building a new branch, jk/date, off of
lt/approxidate, salvaged from origin/pu. I did "git rebase -i
origin/master" and accidentally rewrote the early part of
lt/approxidate.
> Now, basically "git svn rebase" is pretty much git-svn's "pull". Maybe
> its idea could be taken, so we get "git pull --local" to just skip the
> fetch part, but keep "git rebase" and "git merge" 'dumb', requiring
> explicit arguments.
That wouldn't help me, because you can't "pull -i". :)
-Peff
^ permalink raw reply
* Re: how to skip branches on git svn clone/fetch when there are errors
From: Eric Wong @ 2009-09-05 6:16 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <9accb4400908310126v15b08c7fr425c9daff26012f3@mail.gmail.com>
Daniele Segato <daniele.bilug@gmail.com> wrote:
> Hi,
>
> I'm trying to clone a big repository.
>
> I follow this steps:
>
> git init
> git svn init svn://svn.mydomain.com/path/to/repo -T HEAD -b BRANCHES -t TAGS
>
> vim .git/config # edited the svn-remote config as follow (add /root to
> branches and tag) to match the repo structure
> [svn-remote "svn"]
> url = svn://svn.mydomain.com
> fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
> branches = path/to/repo/BRANCHES/*/root:refs/remotes/svn/*
> tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
>
> git svn fetch
>
> When I reach revision ~7500 (I don't remember the exact number) I get an error:
>
> $ git svn fetch
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/SVN/Core.pm line 584.
> Authorization failed: at /usr/bin/git-svn line 1415
>
>
> After some debugging I found out the reason is something strange on
> the SVN server: there is a folder in the SVN that give an error when
> trying to access:
>
> $ svn info svn://svn.mydomain.com/path/to/repo/BRANCHES/V2.1-A
> svn: Authorization failed
>
> The same error with svn list.
>
> I don't know what's wrong with that branch but I just want to skip it...
Ouch :(
> I tried modifying the .git/config svn-remote configuration adding this:
>
> ignore-paths = path\\/to\\/repo\\/BRANCHES\\/V2\\.1-A
> and re-launching git svn fetch.
ignore-paths is only for paths that get converted into part of
the git tree
> I had no luck.
>
> Ho do I skip a path on the svn repository?
It's unfortunate, but there's not yet an exclude/ignore directive
when globbing. You'll have to change your $GIT_CONFIG to only
have a list of branches you want, something like this:
[svn-remote "svn"]
url = svn://svn.mydomain.com
fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
; have one "fetch" line for every branch except the one you want
fetch = path/to/repo/BRANCHES/a/root:refs/remotes/svn/a
fetch = path/to/repo/BRANCHES/b/root:refs/remotes/svn/b
fetch = path/to/repo/BRANCHES/c/root:refs/remotes/svn/c
; you can do the same for tags if you have the same problem
tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
But you shouldn't have to worry about having "fetch" entries for
stale/old branches/tags you've already imported.
--
Eric Wong
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jeff King @ 2009-09-05 6:18 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: SZEDER Gábor, git
In-Reply-To: <20090904070216.GA3996@darc.dnsalias.org>
On Fri, Sep 04, 2009 at 09:02:16AM +0200, Clemens Buchacher wrote:
> On Wed, Sep 02, 2009 at 04:19:17AM -0400, Jeff King wrote:
>
> > [1] I would prefer "git add -u ." to add only the current directory, and
> > "git add -u" to touch everything.
>
> FWIW, I feel the same way. And there is no easy way to do that now. (cd `git
> rev-parse --show-cdup`; git add -u) ?
I suspect it is too late to change it due to compatibility issues. OTOH,
I think the intent of v1.7.0 is to allow a few small breakages like
these. You could always write an RFC patch and generate some discussion;
I'm not 100% sure that there are enough people that agree with us to
change the default.
I guess we could add a "git add --absolute" option, though it is
slightly annoying, because I generally do not realize that I needed to
use such an option until several minutes after running "git add".
I would be fine with a "be absolute, not relative" config option such as
what we have for status (in fact, a global "be absolute, not relative"
option to cover all commands might be handy). The only obstacle is that
I think "git add" is often used as plumbing in scripts (arguably, they
should be using update-index, but "git add ." is just so convenient).
-Peff
^ permalink raw reply
* Re: Hosting Git repositories: how useful will git-gc be?
From: Jeff King @ 2009-09-05 6:24 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq1vmo9xai.fsf@bauges.imag.fr>
On Thu, Sep 03, 2009 at 11:45:25AM +0200, Matthieu Moy wrote:
> A question: is it necessary/recommanded/useless to set up a cron job
> doing a "git gc" in each repository? My understanding is that a push
> through ssh will do some packing, is it correct? Does receiving a pack
> trigger a "git gc --auto"?
The objects are transferred as a pack. If the number of objects is less
than receive.unpackLimit (default 100), then they are unpacked to loose
objects. If more, we keep the pack, after completing any missing deltas
used by a thin pack.
So if you tend to push frequently, you will end up with a lot of loose
objects. Even if you have packs, they will be larger than necessary
because you will be missing deltas between objects across packs. And of
course you will eventually end up with a large number of packs, which is
less efficient (each pack has an index, but I believe we search the
indices linearly).
Receiving a pack does not (AFAICT looking at the code) trigger a "gc
--auto". Running it has other benefits, too, like pruning cruft and
packing refs. So I think it is probably a good idea to run it
periodically.
Running it daily or weekly is probably reasonable. You could run it on
every push using the post-update hook, but that may cause excessive I/O
for very little benefit.
-Peff
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-05 6:28 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090903011234.GA7415@gmail.com>
On Wed, Sep 02, 2009 at 06:12:36PM -0700, David Aguilar wrote:
> The only use case would be for --amend.
> Which is why I asked about --porcelain; really what I want is
> something like
>
> git status --porcelain HEAD^
>
> Rolling a patch to make --porcelain an alias for --short seems
> like a good idea. If we want to support HEAD^ and HEAD^ only
> then perhaps an --amend flag is useful.
>
> The real crux of my question was about being able to script
> it, which is why commit --dry-run is not enough.
I see. I still think you may want to improve "commit --dry-run" with a
plumbing format, though, instead of "git status". Then it would
automagically support "--amend", as well as other dry-run things (e.g.,
"git commit --dry-run --porcelain --amend foo.c"). And not having looked
at the code, I would guess it is a one-liner patch to switch the "output
format" flag that commit passes to the wt-status.c code.
-Peff
^ permalink raw reply
* unpack-trees traversing with index quite broken...
From: Junio C Hamano @ 2009-09-05 6:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Linus,
I found an issue I do not know how to resolve.
Suppose you try to merge these three trees:
- Tree #1 (ancestor)
t tree, in which there is an entry f that is a blob
t/f blob
- Tree #2 (ours)
t blob
t-f blob
- Tree #3 (theirs)
t-f blob
The index matches our tree.
The callchain that causes "read-tree -m -u #1 #2 #3" misbehave looks like this.
unpack_trees()
->traverse_trees()
entry[0] = "t" (tree taken from Tree #1)
entry[1] = "t" (blob taken from Tree #2)
entry[2] = nothing
->unpack_callback()
ce = "t" (blob taken from the index)
->unpack_nondirectories()
src[0] = "t" (blob from the index)
src[1] = conflict (tree taken from Tree #1)
src[2] = "t" (blob taken from Tree #2)
src[3] = NULL
->call_unpack_fn()
This callback is perfectly fine.
/* Now handle any directories.. unpack-trees.c, ll.336- */
->traverse_trees_recursive()
Now we stepped into tree "t".
->traverse_trees()
entry[0] = "f" (blob from "t/" tree in Tree #1)
entry[1] = nothing (Tree #2 does not have "t/" subtree)
entry[2] = nothing (Tree #3 does not have "t/" subtree)
->unpack_callback()
ce = "t-f" (blob taken from the index)
->compare_entry(ce, entry[])
<- "t-f" comes anything in "t/" directory, return negative
Because we are processing "t/something" at this level, and
"t-f" that should come earlier than any "t/something", we
assume that there is no matching entries in the trees.
->unpack_index_entry(ce = "t-f")
->call_unpack_fn()
This callback is utterly wrong. "t-f" from the index
has a matching entry in Tree #2 and Tree #3, but we
haven't seen them yet!
At first, I thought that we could fudge this particular example by
noticing that "t-f" is earlier only because "t-f" sorts before "t/", the
path-prefix of the problematic level, and pretend the negative return from
compare_entry() as if it was positive (i.e. deferring the processing of
the index entry). While this approach lets the problematic level
correctly feed only "t/f" to call_unpack_fn() and come back, and the rest
may proceed cleanly for this particular case, I do not think it is the
right solution.
If Tree #3 had another tree "t/" in it, the situation would look like this
instead:
- Tree #1 (ancestor)
t tree, in which there is an entry f that is a blob
t/f blob
- Tree #2 (ours, matches the index)
t blob
t-f blob
- Tree #3 (theirs)
t-f blob
t tree, in which there is an entry f that is a blob
Since traverse_trees() wants to walk the trees in parallel, never seeking
back, I do not think it would feed t-f from Tree #2 and Tree #3 to the
unpack_callback() sanely. Worse yet, the logic to walk the index in
parallel while this is happening (i.e. "Are we supposed to look at the
index too?" part) does not want to seek o->pos pointer back either, so I
am stuck X-<...
^ permalink raw reply
* Re: [git-svn] always prompted for passphrase with subversion 1.6
From: Eric Wong @ 2009-09-05 6:46 UTC (permalink / raw)
To: Tim Potter; +Cc: git
In-Reply-To: <4A95D58C.1070409@hp.com>
Tim Potter <tpot@hp.com> wrote:
> Hi everyone. I am using git-svn with the Subversion 1.6 client compiled
> with GNOME Keyring support. This neat features allows a SSL client
> certificate password to be cached inside GNOME Keyring instead of being
> prompted to enter it every time. However the git-svn script doesn't
> appear to know about this and always prompts for a password.
>
> Obviously there's some tweak required in the _auth_providers()
> subroutine but I don't know enough about the Subversion Perl client to
> figure out a fix.
>
> Has anyone else run in to this problem? I did a quick search on the
> list but didn't find anything relevant.
Hi Tim,
I think one user wanted to get SSL certificate authentication going but
my SSL knowledge was too weak at the time[1] and I think we both forgot
about it or lost interest.
[1] and probably still so, though I have recently managed to set
*something* up with SSL client certs and maybe it's done
right. SSL is just one of those things that never really
"clicked" for me (ssh on the other hand...)
--
Eric Wong
^ permalink raw reply
* Use case I don't know how to address
From: Alan Chandler @ 2009-09-05 7:02 UTC (permalink / raw)
To: git
I have a use case that I don't know how to address. I have a feeling
that the way I propose is not using git to its best advantage, and am
therefore asking for advice.
As an intermittent software developer I have been using git for a long
time to track software (GPL licenced) I have developed for a web site
that I operate supporting a fan club. [Ajax based Chat, a real time Air
Hockey Game with associated club Ladder, and an American Football
Results Picking Competition]
Each application uses a pattern like that shown below
Basically I have two branches that interact as follows
2' - 2a - 3' - 4' SITE
/ / /
1 - 2 ------ 3 - 4 MASTER
I develop and test Locally on the master branch, in the commit 2a I
update settings (such as database password etc that I need for the
site), and then progressively merge commits made on master when I am
happy that they work in the test environment. A git hook rsyncs the
site branch to site on each merge or commit on that branch.
The master branch is also pushed to my public git repository (which is
why passwords are changed on the site branch. The change made back in
2a is "remembered" by git, so provided I don't go editing the password
on the master branch things work fine.
My applications tend to be "skinned" (if that is the right word for the
html page that forms the backdrop for them) with the fan club web site
look and feel. However, I am now trying to make a demo site on my home
server for these applications, and as such I would like to remove the
fan club skinning and add my own look and feel. In fact there are other
changes necessary, because many of the applications use the associated
fan club membership information of the user to display - so generically,
I need to make quite a lot of modifications to make it all work and
would end up with 4 branches as shown, with the difference in commits
between 4 and 5 as that major work to update the application.
2' - 2a - 3' - 4' SITE
/ / /
1 - 2 ------ 3 - 4 TEST
\
5 ------ 6 MASTER
\ \
5' - 5a- 6' DEMO
As you can see, in the process I have renamed Master to Test - the
transition to 5a adds passwords to access the database on my demo site.
The problem comes when I want to now merge back further work that I did
on the master branch (the 5-6 transition) to the fan club site
2' - 2a - 3' - 4' ----------------- 6' SITE
/ / / /
1 - 2 ------ 3 - 4 ------------6'''- 6a TEST
\ /
5 ------ 6 MASTER
\ \
5''- 5a- 6'' DEMO
What will happen is the changes made in 4->5 will get applied to the
(now) Test branch as part of the 6->6'' merge, and I will be left having
to add a new commit, 6a, to undo them all again. Given this is likely
to be quite a substantial change I want to try and avoid it if possible.
Is there any way I could use git to remember the 4->5 transition,
reverse it and apply it back to the Test branch before hand.
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 7:02 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <20090905061804.GB29863@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I suspect it is too late to change it due to compatibility issues. OTOH,
> I think the intent of v1.7.0 is to allow a few small breakages like
> these. You could always write an RFC patch and generate some discussion;
> I'm not 100% sure that there are enough people that agree with us to
> change the default.
The intent of 1.7.0 is to fix usability glitches and warts that everybody
has long agreed are problematic. People have *just started* discussing
about this---it is not remotely close to "everybody has long agreed are
problematic" criteria. It is too late for 1.7.0.
I agree that there are parts of git that is very whole tree oriented, and
the later "usability" part that are cwd centric. "add -u" and "grep" are
examples of the latter.
I personally find "add -u" that defaults to the current directory more
natural than always going to the root; same preference for "grep".
Besides, "add -u subdir" must add subdir relative to the cwd, without
going to the root. Why should "add -u" sans argument behave drastically
differently?
Speaking of cwd-ness, I sometimes find ls-tree irritating, but I think
this is in "if we had known better we would have designed it differently,
but because we didn't, because many scripts already depend on the current
behaviour, and because we have an --full-name escape hatch, we are not
likely to change it, ever" category.
If "git add -u ../.." (I mean "the grand parent directory", not "an
unnamed subdirectory") did not work, it would be unexcusable and we would
want to devise an migration path, but otherwise I do not think it is such
a big deal. I would say the commands that are used to incrementally build
towards the next commit should be friendly to the practice of limiting the
scope of the work by chdir, i.e. they should be cwd centric. On the other
hand, the commands that are used to review the next commit as a whole,
e.g. diff and patch, should be whole-tree oriented.
Oh, "git grep -e foo ../..", however, does not seem to work. That might be
something people may want to tackle.
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jeff King @ 2009-09-05 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <7v8wgt98ms.fsf@alter.siamese.dyndns.org>
On Sat, Sep 05, 2009 at 12:02:35AM -0700, Junio C Hamano wrote:
> The intent of 1.7.0 is to fix usability glitches and warts that everybody
> has long agreed are problematic. People have *just started* discussing
> about this---it is not remotely close to "everybody has long agreed are
> problematic" criteria. It is too late for 1.7.0.
What about a config option that could change the behavior? True, the
time-frame for discussion is much shorter, but we are not proposing to
make a change that would affect users who do not agree to it. And I
think the point of giving a long time-frame for discussion is to let
people decide whether a change that users do not agree to may affect
them in a bad way.
The real danger here is that users of the config option may be breaking
an interface that is used by scripts. But I feel that 1.7.0 is probably
the best time in the forseeable future to do that, as script-writers
already must be wary of the version change.
> I personally find "add -u" that defaults to the current directory more
> natural than always going to the root; same preference for "grep".
> Besides, "add -u subdir" must add subdir relative to the cwd, without
> going to the root. Why should "add -u" sans argument behave drastically
> differently?
I agree that there is a certain consistency to the current behavior. But
I also find it terribly annoying, because I _always_ want it to do the
other thing, and it silently accepts the command without even telling
me, leaving me to find out ten minutes later that what I thought was
added was not ("git add", by contrast, yells at you in the same
situation).
I also happen to prefer the other behavior because it is easy to switch
the two options: "git add -u" versus "git add -u .", whereas with
current behavior I am stuck calculating (and typing) the correct number
of "../" markers.
But I respect the fact that even if we had infinite time for discussion,
there would be people who prefer it the opposite way to me. So how about
that config option?
> Speaking of cwd-ness, I sometimes find ls-tree irritating, but I think
> this is in "if we had known better we would have designed it differently,
> but because we didn't, because many scripts already depend on the current
> behaviour, and because we have an --full-name escape hatch, we are not
> likely to change it, ever" category.
I assume you mean "ls-files". I have every once in a while been annoyed
by that, but given how infrequently I run ls-files, it is not a big
deal. :)
> If "git add -u ../.." (I mean "the grand parent directory", not "an
> unnamed subdirectory") did not work, it would be unexcusable and we would
> want to devise an migration path, but otherwise I do not think it is such
> a big deal. I would say the commands that are used to incrementally build
As I mentioned above, not only is that annoying to use, but the real
problem is that I _expect_ the other behavior and it silently does the
opposite of what I want. You can argue that my brain is defective (for
not remembering, I mean -- we _know_ it's defective in other ways), but
certainly a config option would be useful to me.
> Oh, "git grep -e foo ../..", however, does not seem to work. That might be
> something people may want to tackle.
Thanks for mentioning "git grep"; I had forgotten that I have been
bitten by expecting full-tree behavior from that in the past, too. A
config option should cover that, too. ;)
-Peff
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 7:25 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <7v8wgt98ms.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> I suspect it is too late to change it due to compatibility issues. OTOH,
>> I think the intent of v1.7.0 is to allow a few small breakages like
>> these. You could always write an RFC patch and generate some discussion;
>> I'm not 100% sure that there are enough people that agree with us to
>> change the default.
>
> The intent of 1.7.0 is to fix usability glitches and warts that everybody
> has long agreed are problematic. People have *just started* discussing
> about this---it is not remotely close to "everybody has long agreed are
> problematic" criteria. It is too late for 1.7.0.
I just wanted to see if I am being fair. Here are the topics that we may
have in 1.7.0.
* jc/1.7.0-push-safety
Prevents gremlin updates from sideways to a repository with a work
tree, that confused countless new people. I've resisted this change
for a long time on the backward compatiblity ground, but it is very
fair to say that it was long agreed that the benefit from the change
far outweigh the donesides of having to say "I do want the old
behaviour" by setting an configuration variable or two.
* jc/1.7.0-send-email-no-thread-default
Defaults multi-message send-email to thread shallowly. This change was
requested by kernel folks for a long time ago, and discussion on-list
resulted in a declaration that unless nobody objects 1.6.2 release
notes will say the default will change in 1.6.3. We did not hear any
objection, but the switchover did not happen ;-).
* jc/1.7.0-status
Everybody hated that "status $args" being "commit --dry-run $args"
since 1.4.0 days. We will give "commit --dry-run $args" in 1.6.5.
* jc/1.7.0-diff-whitespace-only-status
We said "diff -w" only affects the appearance but not the exit code, so
"diff -w --exit-code" never returned success if there were only
whitespace changes. It was noticed to be illogical since day one
of the introduction of --exit-code, but we simply did not bother to fix
the implementation of -b and -w, since the combination of these two
options were thought to be unlikely, and we were simply lazy ;-)
I think the first three are clearly 1.7.0 candidates, judging from the
benefit/downside perspective and also from the escape-hatch perspective,
The last one is probably less so, but on the other hand it is of far
lessor impact that we could even roll it out as a bugfix on 'maint'.
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 7:58 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <20090905072017.GA5152@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I assume you mean "ls-files". I have every once in a while been annoyed
> by that, but given how infrequently I run ls-files, it is not a big
> deal. :)
I did mean ls-tree, but I misspelled the name of the escape hatch.
Try this:
$ cd Documentation
$ git ls-tree HEAD
If I were designing this as a proper plumbing command from scratch, I
wouldn't have given it a cwd behaviour. ls-files is somewhat more
understandable, as it has other cruft relating the work tree, but ls-tree
is worse:
$ cd Documentation
$ git ls-tree origin/html
Whoa??? Yes, it tried to do what "git ls-tree origin/html:Documentation"
would have done if it were unaware of cwd. It's just crazy.
>> If "git add -u ../.." (I mean "the grand parent directory", not "an
>> unnamed subdirectory") did not work, it would be unexcusable and we would
>> want to devise an migration path, but otherwise I do not think it is such
>> a big deal. I would say the commands that are used to incrementally build
>
> As I mentioned above, not only is that annoying to use, but the real
> problem is that I _expect_ the other behavior and it silently does the
> opposite of what I want. You can argue that my brain is defective (for
> not remembering, I mean -- we _know_ it's defective in other ways), but
> certainly a config option would be useful to me.
At this moment (as my brain is not quite functioning), I can only say we
agreed to disagree what feels more natural here.
^ 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