* Re: Revisiting metadata storage
From: Jonathan Nieder @ 2011-11-24 1:10 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Git List, Joey Hess, David Barr
In-Reply-To: <CAD77+gQB+0zJG62jrtPn_MwLLR7zgH=5gBtkvPxrKgiLPZsbsw@mail.gmail.com>
Richard Hartmann wrote:
> To make a long story short: Does anyone have a working solution,
> today?
Sure. etckeeper handles metadata such as owner and permissions
reasonably well.
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Philippe Vaucher @ 2011-11-23 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder
In-Reply-To: <7vlir6brjw.fsf@alter.siamese.dyndns.org>
>> "I want to discard my changes" --> git reset --all HEAD^
>
> That is discarding your changes and also the last commit.
Yes, of course.
>> "I want to discard the last commit" --> git reset --index HEAD^
>
> I do not think this has a clear meaning. "discard the last commit but
> leave the contents in the working tree. I do not care a newly added files
> are forgotten by the index, I'll remember to re-add them if I need to" is
> what you are saying here, but the word "index" does not hint it. When
> used as an option name, "--index" means "this command usually works on or
> touches working tree but for this invocation please also affect the index";
> "please look at or affect _only_ the index" is usually spelled "--cached".
Well, it's certainly a bit more descriptive and easy to remember than
"--mixed". I understand it could confuse people because of the other
commands, but maybe something like "--index-only"?
> In any case, I think your proposal makes it even worse than the current
> state, and you should aim higher.
Why worse? I'd understand if you said it's doesn't improve it enough
for it to be worth the change tho.
Anyway, my proposal was to get a discussion going, and I'm all for
aiming higher if there's a way. What do you propose instead? You
seemed to imply we'd remove --soft and --merge, and make --keep as an
option for --hard but named differently, something like
--keep-changes. Maybe I didn't fully understand.
Mathieu even suggested that it'd have the behavior of --keep by
default, and that you have to add --force to get today's --hard
behavior, which sounds like a good idea to me (avoid destructive
behavior by default).
Philippe
^ permalink raw reply
* Re: [PATCH] run-command.c: Accept EACCES as command not found
From: Frans Klaver @ 2011-11-23 22:55 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Junio C Hamano
In-Reply-To: <CAH6sp9N2ycsoU=is3BVanH33CowD+sMNmWq=Z1MsPJX=HGYY+g@mail.gmail.com>
On Wed, 23 Nov 2011 09:17:43 +0100, Frans Klaver <fransklaver@gmail.com>
wrote:
> On Tue, Nov 22, 2011 at 10:31 AM, Frans Klaver <fransklaver@gmail.com>
> wrote:
>
>> If git is going to do some diagnostics on why the execvp returned
>> EACCES, it can still give a few hints. Most of the more likely options
>> are then ruled out.
>
> If there are no objections, I'm going to cook up a patch that
>
> - Keeps the current behavior (bail on EACCES)
> - Adds a more helpful diagnostic message somewhat like libexplain's,
> but more terse and if possible with slightly more domain knowledge
> - Takes into account the notes made following
> http://article.gmane.org/gmane.comp.version-control.git/171838
So here be some tests I intend to use (based on t0061.3):
run_command reports EACCES, file permissions:
cat hello-script >hello.sh &&
chmod -x hello.sh &&
test_must_fail test-run-command run-command ./hello.sh 2>err &&
grep "fatal: cannot exec.*hello.sh" err
run_command reports EACCES, search path permisions:
mkdir -p inaccessible &&
PATH=$(pwd)/inaccessible:$PATH &&
export PATH &&
cat hello-script >inaccessible/hello.sh &&
chmod 400 inaccessible &&
test_must_fail test-run-command run-command hello.sh 2>err &&
grep "fatal: cannot exec.*hello.sh" err &&
grep "incorrect PATH entry" err
run_command reports EACCES, interpreter fails:
cat incorrect-interpreter-script >hello.sh &&
chmod +x incorrect-interpreter-script &&
chmod -x someinterpreter &&
test_must_fail test-run-command run-command ./hello.sh 2>err &&
grep "fatal: cannot exec.*hello.sh" err &&
grep "cannot execute interpreter" err
Possibly getting (over)ambitious on the interpreter test, but hey, gotta
aim high.
If anybody has a test case that isn't covered, I'd be much obliged.
Frans
^ permalink raw reply
* Re: [PATCH] Fix https interactive authentication problem
From: Jeff King @ 2011-11-23 22:51 UTC (permalink / raw)
To: Steinmann Ruedi; +Cc: git@vger.kernel.org, gitster@pobox.com
In-Reply-To: <F6A589D6B10801478E0DE246A9EF187C1BD5E8@MBX12.d.ethz.ch>
On Wed, Nov 23, 2011 at 07:58:02AM +0000, Steinmann Ruedi wrote:
> Cloning a repository over https works fine when the username/password is
> given in the URL. But if it is queried interactively, an error occurs(see below).
> I found that the username/password is not set when a connection is reused.
>
> With this patch, the username/password is set whenever a connection is reused.
>
> Sample output showing the error:
>
> git clone https://n.ethz.ch/student/...
> Cloning into ...
> Username:
> Password:
> error: Unable to get pack file https://n.ethz.ch/student/.../objects/pack/pack-1ced2ebff0c9fc1f07e0c7cc9dd3fc75f6ac6962.pack
> The requested URL returned error: 401
> ...
> error: Fetch failed.
Hmm. What version of git are you using?
We used to always set up the auth information in get_curl_handle, so all
handles had any auth information that we already got. But we removed
that recently in 986bbc0 (http: don't always prompt for password,
2011-11-04), which is in v1.7.8-rc1 and later.
I'm wondering if this was an unintended side effect of that patch.
Usually git will notice the 401 and retry with credentials (requesting
them from the user if necessary). That used to not work for all requests
but I fixed that in 8d677ed (http: retry authentication failures for all
http requests, 2011-07-18), which is also in v1.7.8-rc*.
However, it looks like the packfile-fetching code for dumb http does not
actually go through the usual http_request method, and does not
recognize the 401.
So if you are using v1.7.8-rc*, then I think that is the issue. And your
patch is just undoing what 8d677ed did. But the right fix is to refactor
the packfile-fetching function on top of the other http-fetching code,
so it can get the benefit of that logic.
If you are using an older version of git (pre-8d677ed), then one guess
about what is happening is a race condition with setting up multiple
curl handles:
1. we get curl handle 1 from get_curl_handle, calling
init_curl_http_auth. But we have no username in the url, so we
assume no credentials are needed.
2. we get curl handle 2 from get_curl_handle, as above.
3. we make a request on handle one, get a 401, and ask for
credentials.
4. we make a request for a packfile on handle 2, but we never copied
the auth from step (3) into the curl handle from step (2), and it
fails.
(I haven't looked closely at our usage of curl_multi_*, so I am not 100%
sure that this can even happen. So consider it just a theory).
If this is the case, your fix works because it calls init_curl_http_auth
more often (i.e., before making any request, not just when we create the
handle). But that means it is also undoing what 8d677ed did; we will ask
the user for credentials before actually seeing a 401.
We could still fix this by teaching the packfile-fetching code to
respect 401s. However, it does incur an unnecessary round-trip (we
already know from the other request that credentials are required, but
we don't bother to use them).
So I think the logic you want instead is "if we already have
credentials, use them with this curl slot, but otherwise don't bother
the user". Which would mean splitting the prompting bit out of
init_curl_http_auth.
-Peff
^ permalink raw reply
* Re: git fetch overwriting local tags
From: Jeff King @ 2011-11-23 22:16 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, John Kacur
In-Reply-To: <20111123090821.GL19986@pengutronix.de>
On Wed, Nov 23, 2011 at 10:08:21AM +0100, Uwe Kleine-König wrote:
> John and I wondered about git fetch overwriting local tags. I was sure
> enough to claim that git fetch won't overwrite local tags with remote
> tags having the same name. But after John pointed me to
>
> http://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/
>
> I tested that (using Debian's 1.7.7.3) and really, git does overwrite
> local tags.
>
> Here is my test script:
> [...]
> git fetch --tags ../a
> [...]
> Is this intended?
Sort of.
By default, "git fetch" will "auto-follow" tags; if you fetch a commit
which is pointed to by a tag, then git will fetch that tag, too. So
generally, you shouldn't need to specify "--tags" at all, because you
will already be getting the relevant tags.
The "--tags" option, however, is a short-hand for saying "fetch all of
the tags", and is equivalent to providing the refspec:
git fetch ../a refs/tags/*:refs/tags/*
Which of course will update your local tags with similarly-named ones
from the remote. So in that sense, there is no bug, and it is working
as intended; the problem is that the author's intent was not the same as
your intent. :)
I'm not sure why you're using "--tags" in the first place. That might
help us figure out if there's another way to do what you want that is
safer.
That being said, it would be nice if "--tags" wasn't so surprising.
Three things that I think could help are:
1. We usually require a "+" on the refspec (or "--force") to update
non-fast-forward branches. But there is no such safety on tags
(which generally shouldn't be updated at all). Should we at least
be enforcing the same fast-forward rules on tag fetches (or even
something more strict, like forbidding tag update at all unless
forced)?
2. We don't keep a reflog on tags. Generally there's no point. But
it wouldn't be very expensive (since they don't usually change),
and could provide a safety mechanism here.
3. Keeping tags from remotes in separate namespaces, but collating
them at lookup time. This has been discussed, and I think is
generally a fine idea, but nobody has moved forward with code.
-Peff
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Joshua Jensen @ 2011-11-23 22:08 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jay Soffian, Michael Haggerty, Gerd Knops, git
In-Reply-To: <CACBZZX4qs8-u33bZbrxYS1CrwjTQc=4YOk2SUjtYzL=vc9KYgA@mail.gmail.com>
----- Original Message -----
From: Ævar Arnfjörð Bjarmason
Date: 11/23/2011 1:50 PM
>
>
> Note that Git doesn't only have confusing behavior with refs on
> case-insensitive filesystems. The other day HFS+ users @ work had
> issues because of a case collision in the checked out tree, which
> confused git status et al.
Is core.ignorecase set to true? Is the repository shared with a case
sensitive file system?
I have a patch sitting around for 'git update-index --add' that fixes
some case insensitivity issues, especially when using Git Gui. This
patch complements the core.ignorecase patches I sent in the past.
-Josh
^ permalink raw reply
* Re: svn to git with non-standard layout
From: Bernd Schubert @ 2011-11-23 21:45 UTC (permalink / raw)
To: Frans Klaver; +Cc: git
In-Reply-To: <op.v5e36lxp0aolir@keputer.lokaal>
On 11/23/2011 10:19 PM, Frans Klaver wrote:
> On Wed, 23 Nov 2011 20:23:34 +0100, Bernd Schubert
> <bernd.schubert@itwm.fraunhofer.de> wrote:
>
>> we just want to migrate from subversion to git, but so far all
>> attempts to do that resulted in missing commit information.
>
> What are all attempts? Did you try only git-svn, or did you try tools
> like svn2git?
We are trying to do this ever since Monday and it included svn2git as
well. The problem with svn2git is that you can provide several tags and
branch paths, but only a single trunk path.
>
>
>> Any ideas what I still could try to do?
>
> If you haven't tried anything other than git-svn, try svneverever &
> svn2git[1] for an actual repository conversion. Or have a look at the
> newest kid on the block called SubGit[2][3]. In both I don't have any
> experience, but of svn2git I know Qt and KDE have used it successfully
> to convert their repositories.
>
> I assume both are somewhat more complex to use and set up than to simply
> use git-svn, but I guess it will be worth the effort.
>
> Good luck,
> Frans
>
> [1] http://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git
> [2] http://subgit.com/
> [3] http://thread.gmane.org/gmane.comp.version-control.git/185806
Thanks, I'm going to read about svneverever and SubGit tomorrow. We will
also try another tool that can convert an svn dump (once we get a dump,
as we don't have easy access to the svn database).
Thanks,
Bernd
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Jeff King @ 2011-11-23 21:45 UTC (permalink / raw)
To: Adam Borowski; +Cc: git
In-Reply-To: <20111123200920.GA21004@angband.pl>
On Wed, Nov 23, 2011 at 09:09:20PM +0100, Adam Borowski wrote:
> > But from what directory would you expect:
> >
> > git bisect run make
> >
> > to run from? If you use a GNU-ish layout with all of your code in
> > "src/",
>
> In a vast majority of cases the layout remains constant during the whole
> bisection.
Agreed. But you need to think about what happens when it does not. I
think marking the commit as untestable is probably best, with bisect
barfing a reasonable second. Accidentally marking the commit as "bad" is
probably the worst thing we could do. That would produce a subtly wrong
bisection result.
> > Maybe that commit should be considered indeterminate then?
>
> Why? If you're running an automated command, then it will probably fail,
> yeah. I guess most people bisect manually though, so even in repositories
> that do have this problem, there's someone who can test the given commit
> anyway.
If you're not doing "bisect run", then it is a non-issue, no? If you
are bisecting by hand, then "git bisect good|bad" will delete your
working directory, and probably your shell will start complaining, and
an intelligent tester will see what happened. This is only a problem for
automated bisection, which does not have such a tester.
> > I dunno. I haven't thought that hard about it. But I don't think it's
> > quite as simple as just telling bisect it's OK to run from a subdir.
>
> At the very least, generally working with a caveat in corner cases seems to
> be better than outright failing.
To be clear: I think this is a good feature that will help a lot of
people, and I don't think an uncommon corner case should prevent it from
going into git. But I _do_ think we should consider what happens in the
corner cases and at least fail gracefully, rather than produce subtly
wrong results.
-Peff
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Jeff King @ 2011-11-23 21:36 UTC (permalink / raw)
To: Peter Baumann; +Cc: Junio C Hamano, Adam Borowski, git
In-Reply-To: <20111123202643.GB6291@m62s10.vlinux.de>
On Wed, Nov 23, 2011 at 09:26:43PM +0100, Peter Baumann wrote:
> > If we cd_to_toplevel, we can remember the prefix that we started from
> > and cd to it before running the user's command, but there is no
> > guarantee that it actually exists. Maybe that commit should be
> > considered indeterminate then?
> >
>
> Why not simply fail the run with exit(-1)? If the directory doesn't exist
> in an older commit (which I think is not that common) git bisect should
> simply stop and let the user proceed.
The point of "git bisect run" is to run unattended until we reach an
answer. I don't think most people would be happy with it not running to
come to _some_ answer (e.g., imagine checking the results of an
overnight "bisect run" in the morning only to find that it stopped 20
minutes in).
That's why I think just marking the commit as indeterminate would be
better; it jumps over parts of history that omit the directory, and will
generally still come to a good conclusion. If it's possible to get an
answer, that is. It might say "we can't come up with an answer because
all of these commits are not testable". But that tells you something,
too: your bisection test is not a good one.
> And yes, I find the current behaviour to forbid running git bisect from
> a subdirectory slighly annoying and I'm glad somebody took a stab at it.
Agreed. I often bisect by hand with two terminals, doing something like:
[terminal 1]
git bisect start ...
make
[terminal 2]
cd t
./t1234-whatever -v
[terminal 1]
git bisect good|bad
make
[terminal 2]
./t1234-whatever
And then want to type "git bisect good|bad" into terminal 2. Which
doesn't work, of course (yes, in this simple case I could automate the
running of the test script from terminal 1; but often times it is
simpler to just eyeball the output during the bisection).
-Peff
^ permalink raw reply
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Frans Klaver @ 2011-11-23 21:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paolo Ciarrocchi, Daniele Segato, Git Mailing List, Jeff King,
Scott Chacon
In-Reply-To: <7v4nxudb73.fsf@alter.siamese.dyndns.org>
On Wed, 23 Nov 2011 18:02:08 +0100, Junio C Hamano <gitster@pobox.com>
wrote:
> Frans Klaver <fransklaver@gmail.com> writes:
>
>> The note from the maintainer[1] mentions
>>
>> git://git.kernel.org/pub/scm/git/git.git/
>> git://repo.or.cz/alt-git.git
>> https://github.com/git/git
>> https://code.google.com/p/git-core/
>>
>> I would assume one of those would be a nomination for 'official' repo.
>>
>> Maybe something for Scott C. to address?
>
> As long as the link says "Git source repository" without "the official",
> Scott is doing the right thing. It is just one of the copies that I push
> into, so it may be considered more official than a fork of my history by
> a
> random unknown person.
>
> As Git is distributed, we do not need a single "official" repository. If
> you really want to name one, my private working repository at my home
> machine would be what is closest to one, as patches and pull requests are
> processed there and then the result is pushed out to the above four and a
> few others. But that "official" one is not exposed to the outside world
> ;-)
Since official is a rather unreal term here, let's just drop it. There are
a few repositories that the maintainer currently pushes to, and those are
the most reliable ones to use if you want the latest git vanilla. Other
than that, there's going to be no difference from the next git.git clone.
It might remove some confusion if these repos would be reflected on
websites focusing on git as they are in the maintainers notes, but that's
probably up to the respective webmasters then.
Frans
^ permalink raw reply
* Re: [PATCH] builtin-branch: Fix crash on invalid use of --force
From: Junio C Hamano @ 2011-11-23 21:30 UTC (permalink / raw)
To: vfr; +Cc: git
In-Reply-To: <1322029915-18486-1-git-send-email-vfr@lyx.org>
Makes sense and is a nice fix for a regression on 'master'. Thanks.
^ permalink raw reply
* Re: svn to git with non-standard layout
From: Frans Klaver @ 2011-11-23 21:19 UTC (permalink / raw)
To: git, Bernd Schubert
In-Reply-To: <jajh7m$it7$1@dough.gmane.org>
On Wed, 23 Nov 2011 20:23:34 +0100, Bernd Schubert
<bernd.schubert@itwm.fraunhofer.de> wrote:
> we just want to migrate from subversion to git, but so far all attempts
> to do that resulted in missing commit information.
What are all attempts? Did you try only git-svn, or did you try tools like
svn2git?
> Any ideas what I still could try to do?
If you haven't tried anything other than git-svn, try svneverever &
svn2git[1] for an actual repository conversion. Or have a look at the
newest kid on the block called SubGit[2][3]. In both I don't have any
experience, but of svn2git I know Qt and KDE have used it successfully to
convert their repositories.
I assume both are somewhat more complex to use and set up than to simply
use git-svn, but I guess it will be worth the effort.
Good luck,
Frans
[1] http://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git
[2] http://subgit.com/
[3] http://thread.gmane.org/gmane.comp.version-control.git/185806
^ permalink raw reply
* Re: svn to git with non-standard layout
From: Bernd Schubert @ 2011-11-23 20:52 UTC (permalink / raw)
To: Stephen Bash; +Cc: git
In-Reply-To: <2d5f33eb-c1dc-491a-a8ed-e8ceaaf2e2b1@mail>
On 11/23/2011 09:22 PM, Stephen Bash wrote:
> ----- Original Message -----
>> From: "Bernd Schubert"<bernd.schubert@itwm.fraunhofer.de>
>> To: git@vger.kernel.org
>> Sent: Wednesday, November 23, 2011 2:23:34 PM
>> Subject: svn to git with non-standard layout
>>
>> So we have something like this:
>>
>> svn-root -> main-project
>> / | \
>> / | \
>> proj1 proj2 proj{n}
>> / \ / \ / \
>> / \ / \ trunk tags
>> / \ trunk tags
>> trunk tags
>> / \
>> tag1 tag{2...n}
>
> Just for clarification: are there files and/or directories in main-project that are not sub-projects?
Yes that as well, sorry, forgot to tell about this. If those should be
troublesome, we might simply ignore them, as those are not that
important to have a full history, though.
Thanks,
Bernd
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Ævar Arnfjörð Bjarmason @ 2011-11-23 20:50 UTC (permalink / raw)
To: Jay Soffian; +Cc: Michael Haggerty, Gerd Knops, git
In-Reply-To: <CAG+J_DxREbykWggrD49L7qvR9M36wKL7+_kOYbvcWmLBCF2Gog@mail.gmail.com>
On Tue, Nov 22, 2011 at 18:31, Jay Soffian <jaysoffian@gmail.com> wrote:
> I wonder what the downside would be of always using packed refs on
> case-insenstive file systems. This would seem analogous to how git no
> longer uses symlinks.
Note that Git doesn't only have confusing behavior with refs on
case-insensitive filesystems. The other day HFS+ users @ work had
issues because of a case collision in the checked out tree, which
confused git status et al.
Note that HFS+ in particular is case-insensitive *but* case
preserving. E.g.:
$ touch Foo; perl -wle 'opendir my $d, "."; print while readdir
$d; -f and print "yes" for qw(foo Foo FOO)'
.
..
Foo
yes
yes
yes
On case-insensitive and not-case-preserving systems the third line
would usually print either "foo" or "FOO", but on HFS+ the system
preserves the original name.
This means that you can in some cases figure out what's going on by
doing a readdir() in addition to a stat() as you could do on
POSIX-compliant systems.
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Junio C Hamano @ 2011-11-23 20:45 UTC (permalink / raw)
To: Jeff King; +Cc: Adam Borowski, git
In-Reply-To: <20111123192329.GA21630@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:
>
>> As to the approach, I suspect that it would be far better if it made
>> workable with cd_to_toplevel at the beginning, instead of saying
>> SUBDIRECTORY_OK.
>>
>> After all, the current directory may disappear during the course of
>> bisection, upon checking out a revision that did not have the directory
>> you started your bisection from.
>
> But from what directory would you expect:
>
> git bisect run make
My usual way to enlighten somebody is by forcing him/her to think the
consequences, but because you did the thinking for the OP in this thread
instead, it didn't work. Makes me somewhat sad ;-<.
> If we cd_to_toplevel, we can remember the prefix that we started from
> and cd to it before running the user's command, but there is no
> guarantee that it actually exists. Maybe that commit should be
> considered indeterminate then?
Yeah that sounds like a reasonable thing to do.
> I dunno. I haven't thought that hard about it. But I don't think it's
> quite as simple as just telling bisect it's OK to run from a subdir.
Absolutely. Saying SUBDIRECTORY_OK without thinking about the consequence
through is a good discussion starter but is not a good patch.
Also didn't we make bisect workable in a bare repository recently? So the
start-up sequence has to be something more elaborate like...
. git-sh-setup
if we are in a bare repository
then
: we are happy...nothing funky needs to be done
elif we are not in a working tree
barf
elif we are not at the top
prefix=$(git rev-parse --show-prefix)
cd_to_toplevel
fi
and then inside bisect_next() you would check if $prefix exists, and go
there to run bisect--helper (or fail to go there and say "cannot test").
^ permalink raw reply
* [PATCH] imap-send: Remove unused 'use_namespace' variable
From: Thomas Jarosch @ 2011-11-23 20:32 UTC (permalink / raw)
To: git
Reported by cppcheck
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
---
imap-send.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index e1ad1a4..80e0e8c 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -161,7 +161,6 @@ static struct imap_server_conf server = {
struct imap_store_conf {
struct store_conf gen;
struct imap_server_conf *server;
- unsigned use_namespace:1;
};
#define NIL (void *)0x1
--
1.7.6.4
^ permalink raw reply related
* Re: svn to git with non-standard layout
From: Stephen Bash @ 2011-11-23 20:22 UTC (permalink / raw)
To: Bernd Schubert; +Cc: git
In-Reply-To: <jajh7m$it7$1@dough.gmane.org>
----- Original Message -----
> From: "Bernd Schubert" <bernd.schubert@itwm.fraunhofer.de>
> To: git@vger.kernel.org
> Sent: Wednesday, November 23, 2011 2:23:34 PM
> Subject: svn to git with non-standard layout
>
> So we have something like this:
>
> svn-root -> main-project
> / | \
> / | \
> proj1 proj2 proj{n}
> / \ / \ / \
> / \ / \ trunk tags
> / \ trunk tags
> trunk tags
> / \
> tag1 tag{2...n}
Just for clarification: are there files and/or directories in main-project that are not sub-projects?
Thanks,
Stephen
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Peter Baumann @ 2011-11-23 20:26 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Adam Borowski, git
In-Reply-To: <20111123192329.GA21630@sigill.intra.peff.net>
On Wed, Nov 23, 2011 at 02:23:29PM -0500, Jeff King wrote:
> On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:
>
> > As to the approach, I suspect that it would be far better if it made
> > workable with cd_to_toplevel at the beginning, instead of saying
> > SUBDIRECTORY_OK.
> >
> > After all, the current directory may disappear during the course of
> > bisection, upon checking out a revision that did not have the directory
> > you started your bisection from.
>
> But from what directory would you expect:
>
> git bisect run make
>
> to run from? If you use a GNU-ish layout with all of your code in
> "src/", then I can see it useful to do something like:
>
> cd src
> git bisect run make
>
> If we cd_to_toplevel, we can remember the prefix that we started from
> and cd to it before running the user's command, but there is no
> guarantee that it actually exists. Maybe that commit should be
> considered indeterminate then?
>
Why not simply fail the run with exit(-1)? If the directory doesn't exist
in an older commit (which I think is not that common) git bisect should
simply stop and let the user proceed.
And yes, I find the current behaviour to forbid running git bisect from
a subdirectory slighly annoying and I'm glad somebody took a stab at it.
-Peter
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Adam Borowski @ 2011-11-23 20:09 UTC (permalink / raw)
To: git
In-Reply-To: <20111123192329.GA21630@sigill.intra.peff.net>
On Wed, Nov 23, 2011 at 02:23:29PM -0500, Jeff King wrote:
> On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:
>
> > As to the approach, I suspect that it would be far better if it made
> > workable with cd_to_toplevel at the beginning, instead of saying
> > SUBDIRECTORY_OK.
> >
> > After all, the current directory may disappear during the course of
> > bisection, upon checking out a revision that did not have the directory
> > you started your bisection from.
No different from git-reset or git-checkout.
>
> But from what directory would you expect:
>
> git bisect run make
>
> to run from? If you use a GNU-ish layout with all of your code in
> "src/",
In a vast majority of cases the layout remains constant during the whole
bisection.
> then I can see it useful to do something like:
>
> cd src
> git bisect run make
>
> If we cd_to_toplevel, we can remember the prefix that we started from
> and cd to it before running the user's command, but there is no
> guarantee that it actually exists.
I guess, the best that can be done is going into as many path components as
possible.
> Maybe that commit should be considered indeterminate then?
Why? If you're running an automated command, then it will probably fail,
yeah. I guess most people bisect manually though, so even in repositories
that do have this problem, there's someone who can test the given commit
anyway.
> I dunno. I haven't thought that hard about it. But I don't think it's
> quite as simple as just telling bisect it's OK to run from a subdir.
At the very least, generally working with a caveat in corner cases seems to
be better than outright failing.
If you're paranoid, there's an option of having a config setting "yes, I've
read the manual why automated bisection can fail".
--
1KB // Yo momma uses IPv4!
^ permalink raw reply
* svn to git with non-standard layout
From: Bernd Schubert @ 2011-11-23 19:23 UTC (permalink / raw)
To: git
Hi all,
we just want to migrate from subversion to git, but so far all attempts
to do that resulted in missing commit information.
So we have an svn repo with multiple sub-repos. The trouble is now that
those sub-repos have their own trunk/tags (no branches) directories, but
actually those projects are very dependent on each other and lots of
commits go to many sub-project in a single commit.
So our new git repository shall meld all sub-projects into a new common
repository.
So we have something like this:
svn-root -> main-project
/ | \
/ | \
proj1 proj2 proj{n}
/ \ / \ / \
/ \ / \ trunk tags
/ \ trunk tags
trunk tags
/ \
tag1 tag{2...n}
I think the same issue has been asked a few times before, for example here:
http://comments.gmane.org/gmane.comp.version-control.git/163491
but I still do not know how to properly convert the old structure into a
new global one. So we simply want to have:
branches,tags <- main-project -> {proj1, proj2, ..., projN}
I think the above link suggests something like
[svn-remote "svn"]
url = https://some-repo-url
fetch=/:refs/remotes/svnroot
fetch = build_scripts/trunk:refs/remotes/build_scripts/trunk
fetch = create_repos/trunk:refs/remotes/create_repos/trunk
When I'm going to to 'svn fetch' this, files from different projects are
going to be in the same directory. But of course, the project directory
structure is supposed to stay as it it.
Any ideas what I still could try to do?
Thanks,
Bernd
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Jeff King @ 2011-11-23 19:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Borowski, git
In-Reply-To: <7vd3cibqqe.fsf@alter.siamese.dyndns.org>
On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:
> As to the approach, I suspect that it would be far better if it made
> workable with cd_to_toplevel at the beginning, instead of saying
> SUBDIRECTORY_OK.
>
> After all, the current directory may disappear during the course of
> bisection, upon checking out a revision that did not have the directory
> you started your bisection from.
But from what directory would you expect:
git bisect run make
to run from? If you use a GNU-ish layout with all of your code in
"src/", then I can see it useful to do something like:
cd src
git bisect run make
If we cd_to_toplevel, we can remember the prefix that we started from
and cd to it before running the user's command, but there is no
guarantee that it actually exists. Maybe that commit should be
considered indeterminate then?
I dunno. I haven't thought that hard about it. But I don't think it's
quite as simple as just telling bisect it's OK to run from a subdir.
-Peff
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Junio C Hamano @ 2011-11-23 19:09 UTC (permalink / raw)
To: Adam Borowski; +Cc: git
In-Reply-To: <20111123145034.GB17927@angband.pl>
Adam Borowski <kilobyte@angband.pl> writes:
> The requirement to be in the toplevel directory when calling git-bisect is
> pretty infuriating. I tried to find an explanation for this, and the only
> reference I found was:
>
> http://thread.gmane.org/gmane.comp.version-control.git/27524/focus=27596
Interesting. It used to be that people were thankful when a command
happened to work from a subdirectory, and it was a minor irritation when
some command didn't; in the early days, everything in Git was to be used
from the top-legvel.
> However, since then, git-reset has been changed (in a81c311f). What about
> changing git-bisect as well?
>
> A trivial patch seems to work for me, but I might have missed some corner
> case.
Thanks; read and follow Documentation/SubmittingPatches the next time
perhaps?
As to the approach, I suspect that it would be far better if it made
workable with cd_to_toplevel at the beginning, instead of saying
SUBDIRECTORY_OK.
After all, the current directory may disappear during the course of
bisection, upon checking out a revision that did not have the directory
you started your bisection from.
>
> --
> 1KB // Yo momma uses IPv4!
>
> From 1dd5dda6a9db3d987e15784c4de24e593cc596e0 Mon Sep 17 00:00:00 2001
> From: Adam Borowski <kilobyte@angband.pl>
> Date: Wed, 23 Nov 2011 15:08:42 +0100
> Subject: [PATCH] git-bisect: allow using it from a subdirectory.
>
> Just like git-reset, restricting it to toplevel is an annoyance, and the
> latter has been changed in a81c311f.
> ---
> git-bisect.sh | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 99efbe8..fd6ccdd 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -27,6 +27,7 @@ git bisect run <cmd>...
> Please use "git help bisect" to get the full man page.'
>
> OPTIONS_SPEC=
> +SUBDIRECTORY_OK=Yes
> . git-sh-setup
> . git-sh-i18n
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Junio C Hamano @ 2011-11-23 18:59 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jay Soffian, Gerd Knops, git
In-Reply-To: <4ECCBB3D.7070204@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 11/22/2011 06:49 PM, Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> Currently git handles references names case-sensitively and allows
>>> multiple reference names that differ only in case.
>>
>> We do the same for in-tree paths, by the way. Ultimately, I think the
>> sane thing to do is to appeal to the user's common sense. [...common
>> sense aka "if it hurts don't do it" omitted...]
>>
>> I think refnames have exactly the same issue. In theory, you could have
>> "Master" and "master" branches, and nothing stops you from trying to do
>> so, but in practice, if it is not useful for you and your project, and
>> if it is equally fine to use some other name instead of "Master" for the
>> purpose of you and your project, then there is no strong reason for doing
>> so, unless you are trying to irritate users on case folding platforms.
>
> I agree.
>
> But git could nevertheless help users (1) by providing config settings
> or hook scripts or something that could be configured in a repository to
> prevent case-conflicts from entering the project history; (2) by
> emitting an error when such a conflict arises rather than getting so
> confused.
Yeah, and you didn't have to say "But"; we are in agreement (see my other
message in response to the same message from you).
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Junio C Hamano @ 2011-11-23 18:51 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: git, Christian Couder
In-Reply-To: <CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com>
Philippe Vaucher <philippe.vaucher@gmail.com> writes:
> So if I recap my ideas:
>
> "I want to discard my changes" --> git reset --all HEAD^
That is discarding your changes and also the last commit.
> "I want to discard the last commit" --> git reset --index HEAD^
I do not think this has a clear meaning. "discard the last commit but
leave the contents in the working tree. I do not care a newly added files
are forgotten by the index, I'll remember to re-add them if I need to" is
what you are saying here, but the word "index" does not hint it. When
used as an option name, "--index" means "this command usually works on or
touches working tree but for this invocation please also affect the index";
"please look at or affect _only_ the index" is usually spelled "--cached".
In any case, I think your proposal makes it even worse than the current
state, and you should aim higher. Some modes of "git reset" have
historical reasoning behind their behaviour that cannot be dismissed
easily by somebody who does not understand them, but at the same time some
of them outlived their usefulness and we may want to start thinking about
deprecating them. The first step might be to make them less prominent in
the documentation.
I am guilty of introducing "git reset --soft HEAD^" before I invented
"commit --amend" during v1.3.0 timeframe to solve the issue "soft" reset
originally wanted to. Even though the whole point of the "reset" command
is about "resetting the index", it is an unfortunate oddball that does not
touch the index. It shouldn't have been part of the "reset" command, and
if we were doing Git from scratch today, we probably wouldn't have it
there. What it does is sometimes useful in interactive use and often
useful in scripting, but scripts can use update-ref.
"git reset --hard HEAD" is an unambiguously descriptive good name for the
option. It is a "hard reset" like power cycling a machinery to discard
anything in progress and get back to a clean slate. I do not see anything
confusing with this mode nor its name.
"git reset --keep" was introduced at 9bc454d (reset: add option "--keep"
to "git reset", 2010-01-19) as a short-hand to run something like this.
git checkout -B $current_branch $target_commit
If we made the above command line to work (it errors out saying you cannot
update the current branch) instead of adding it a new mode to "reset", it
would have been much easier to understand what the particular operation
does. You are updating the tip of the branch that happens to be the
current branch to a different commit while carrying the local change with
you.
It also would have made number of options "reset" has smaller by one and
reducing confusion. What it does is too similar to what "reset --merge"
does, which only adds to the confusion.
^ permalink raw reply
* Re: git not resuming push
From: Jeff King @ 2011-11-23 18:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Brossier, git
In-Reply-To: <7vmxbncq5v.fsf@alter.siamese.dyndns.org>
On Tue, Nov 22, 2011 at 10:24:12PM -0800, Junio C Hamano wrote:
> Another possibility, if it is the connection between you and the other
> side that is the problem, is to chunk your push in smaller pieces. That
> is, if you are trying to push out v3.0, you first push only to v1.0, then
> to v2.0, and then finally to v3.0.
>
> Peff, by the way, wouldn't this request reminds of us of a scenario we
> discussed recently, which I said I would imagine would be common while you
> dismissed as not likely to be common?
I didn't say it wasn't common; I said I didn't think it was the majority
case, and that I didn't want a solution that only helped this case
without covering the other cases.
Also, it isn't clear to me that an immediate-reconnect scheme would
work. When the connection gets dropped, is it simply that TCP connection
that goes out, and another one could immediately be made to resume? Or
is the network actually out (even if only for a few seconds)?
-Peff
^ 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