* Re: git fetch overwriting local tags
From: Uwe Kleine-König @ 2011-11-24 7:07 UTC (permalink / raw)
To: Jeff King; +Cc: git, John Kacur
In-Reply-To: <20111123221658.GA22313@sigill.intra.peff.net>
Hi Jeff,
On Wed, Nov 23, 2011 at 05:16:58PM -0500, Jeff King wrote:
> 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.
Hmm, if I do:
mkdir a
cd a
echo some content > some_file
git init
git add some_file
git commit -m 'some commit log'
git tag some_tag
cd ..
mkdir b
cd b
echo some different content > another_file
git init
git add another_file
git commit -m 'another commit log'
git fetch ../a
I don't get the tag. That's why I added --tags. I guess that's because
some_tag is a lightweight tag. Hmm, but even if I change the command to
create the tag to
git tag -a -m 'tag desc' some_tag
I don't get it without --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)?
That sounds fine for me.
> 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.
I prefer 1, but that would be better than the current situation at
least.
> 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.
That's something that John said in our discussion, too. That's the
suggestion I like the most.
Best regards and thanks for your time,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Peter Baumann @ 2011-11-24 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Adam Borowski, git
In-Reply-To: <7vzkfma7q9.fsf@alter.siamese.dyndns.org>
On Wed, Nov 23, 2011 at 12:45:18PM -0800, Junio C Hamano wrote:
> 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").
>
But is the "cannot test" aka exit(127) the best we can do in this case?
I think having a failing make, because someone has checked in code which doesn't
even compile, is something totally different than having no Makefile at all,
because the directory doesn't even exist. To me, this seems more like an error
in the run script to not handle all the cases of the (dis)appearing directory.
On the other hand we don't waste much time trying to test such an "untestable"
commit, because this check will be fast because no compiling is involved.
The only time wasted will bethe build time for the "usable" commits and the
time the user needs to figure out why the heck some(/most?) of his commits
are "untestable".
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-24 5:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vlir69k0s.fsf@alter.siamese.dyndns.org>
On Thu, Nov 24, 2011 at 12:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> ...
>>>> I think we should do this regardless precious being added or not.
>>>
>>> Because (see below)?
>>
>> Because it may potentially lose user's changes. Assume file "A" is
>> tracked and also ignored. Users may make some changes in A, then move
>> HEAD away without touching worktree, now HEAD does not see "A" as
>> tracked any more.
>
> Huh? "A" is initially tracked and the user modifies it. Moving HEAD away
> how? "git checkout" would refuse to check out a branch that has different
> contents at "A", or is missing "A". So how can "now HEAD does not see 'A'
> as tracked any more" happen?
git reset <somewhere else>
--
Duy
^ permalink raw reply
* [PATCH] bulk-checkin: honor pack.packsizelimit
From: Junio C Hamano @ 2011-11-24 5:18 UTC (permalink / raw)
To: git
In-Reply-To: <1321600317-30546-1-git-send-email-gitster@pobox.com>
The bulk-checkin interface is designed to throw multiple blobs into a
single output packfile during the lifetime of a single process by
"plugging" the output. The direct streaming of the data to a packfile
however is primarily meant as a way to deal with large blobs better, and
it is possible that we end up with a single humongous packfile that is
awkward to handle.
Pay attention to the pack.packsizelimit configuration the same way as
the pack-object does, and make sure we close a packfile and switch to a
new one before busting the size limit.
We allow the limit to be busted if a single object is too large to be
contained in a pack that is smaller than the limit on its own, as there is
no way to store such an object otherwise; the same is already done in
pack-objects.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/pack-objects.c | 6 +-----
bulk-checkin.c | 35 ++++++++++++++++++++++++++++++-----
cache.h | 1 +
config.c | 4 ++++
environment.c | 1 +
5 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index b458b6d..dde913e 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -76,7 +76,7 @@ static struct pack_idx_option pack_idx_opts;
static const char *base_name;
static int progress = 1;
static int window = 10;
-static unsigned long pack_size_limit, pack_size_limit_cfg;
+static unsigned long pack_size_limit;
static int depth = 50;
static int delta_search_threads;
static int pack_to_stdout;
@@ -2009,10 +2009,6 @@ static int git_pack_config(const char *k, const char *v, void *cb)
pack_idx_opts.version);
return 0;
}
- if (!strcmp(k, "pack.packsizelimit")) {
- pack_size_limit_cfg = git_config_ulong(k, v);
- return 0;
- }
return git_default_config(k, v, cb);
}
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 60178ef..2adc67b 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -73,10 +73,13 @@ static int already_written(struct bulk_checkin_state *state, unsigned char sha1[
return 0;
}
-static void deflate_to_pack(struct bulk_checkin_state *state,
- unsigned char sha1[],
- int fd, size_t size, enum object_type type,
- const char *path, unsigned flags)
+#define DEFLATE_TO_PACK_OK 0
+#define DEFLATE_TO_PACK_TOOBIG 1
+
+static int deflate_to_pack(struct bulk_checkin_state *state,
+ unsigned char sha1[],
+ int fd, size_t size, enum object_type type,
+ const char *path, unsigned flags)
{
unsigned char obuf[16384];
unsigned hdrlen;
@@ -149,6 +152,13 @@ static void deflate_to_pack(struct bulk_checkin_state *state,
sha1file_truncate(state->f, &checkpoint);
state->offset = checkpoint.offset;
free(idx);
+ } else if (state->nr_written &&
+ pack_size_limit_cfg &&
+ pack_size_limit_cfg < state->offset) {
+ sha1file_truncate(state->f, &checkpoint);
+ state->offset = checkpoint.offset;
+ free(idx);
+ return DEFLATE_TO_PACK_TOOBIG;
} else {
hashcpy(idx->sha1, sha1);
ALLOC_GROW(state->written,
@@ -156,12 +166,17 @@ static void deflate_to_pack(struct bulk_checkin_state *state,
state->written[state->nr_written++] = idx;
}
}
+ return DEFLATE_TO_PACK_OK;
}
int index_bulk_checkin(unsigned char *sha1,
int fd, size_t size, enum object_type type,
const char *path, unsigned flags)
{
+ off_t seekback;
+ int status;
+
+again:
if (!state.f && (flags & HASH_WRITE_OBJECT)) {
state.f = create_tmp_packfile(&state.pack_tmp_name);
reset_pack_idx_option(&state.pack_idx_opts);
@@ -171,7 +186,17 @@ int index_bulk_checkin(unsigned char *sha1,
die_errno("unable to write pack header");
}
- deflate_to_pack(&state, sha1, fd, size, type, path, flags);
+ seekback = lseek(fd, 0, SEEK_CUR);
+ if (seekback == (off_t) -1)
+ return error("cannot seek");
+ status = deflate_to_pack(&state, sha1, fd, size, type, path, flags);
+ if (status == DEFLATE_TO_PACK_TOOBIG) {
+ finish_bulk_checkin(&state);
+ if (lseek(fd, seekback, SEEK_SET) == (off_t) -1)
+ return error("cannot seek back");
+ goto again;
+ }
+
if (!state.plugged)
finish_bulk_checkin(&state);
return 0;
diff --git a/cache.h b/cache.h
index 2e6ad36..b158d3e 100644
--- a/cache.h
+++ b/cache.h
@@ -598,6 +598,7 @@ extern size_t packed_git_window_size;
extern size_t packed_git_limit;
extern size_t delta_base_cache_limit;
extern unsigned long big_file_threshold;
+extern unsigned long pack_size_limit_cfg;
extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
diff --git a/config.c b/config.c
index edf9914..c736802 100644
--- a/config.c
+++ b/config.c
@@ -797,6 +797,10 @@ int git_default_config(const char *var, const char *value, void *dummy)
return 0;
}
+ if (!strcmp(var, "pack.packsizelimit")) {
+ pack_size_limit_cfg = git_config_ulong(var, value);
+ return 0;
+ }
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 0bee6a7..31e4284 100644
--- a/environment.c
+++ b/environment.c
@@ -60,6 +60,7 @@ char *notes_ref_name;
int grafts_replace_parents = 1;
int core_apply_sparse_checkout;
struct startup_info *startup_info;
+unsigned long pack_size_limit_cfg;
/* Parallel index stat data preload? */
int core_preload_index = 0;
--
1.7.8.rc3.208.g1edbd
^ permalink raw reply related
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-24 5:17 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <CACsJy8BYN-nu6a92dk-qpF5_jR_frKwg+DD1EThr2kMPGHV5kQ@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> ...
>>> I think we should do this regardless precious being added or not.
>>
>> Because (see below)?
>
> Because it may potentially lose user's changes. Assume file "A" is
> tracked and also ignored. Users may make some changes in A, then move
> HEAD away without touching worktree, now HEAD does not see "A" as
> tracked any more.
Huh? "A" is initially tracked and the user modifies it. Moving HEAD away
how? "git checkout" would refuse to check out a branch that has different
contents at "A", or is missing "A". So how can "now HEAD does not see 'A'
as tracked any more" happen?
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-24 1:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vy5v6bvy4.fsf@alter.siamese.dyndns.org>
On Thu, Nov 24, 2011 at 12:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Mon, Nov 21, 2011 at 10:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> In the medium term, I think one reasonable way forward solving the "TODO
>>> that used to be tracked but now untracked and ignored" issue is to
>>> introduce "info/exclude-override" that comes between command line and
>>> in-tree patterns. The info/exclude file is designed as the fallback
>>> definition to be used when all other sources are too lax, and comes near
>>> the precedence stack; the "TODO" situation however calls for an override
>>> that is stronger than the in-tree patterns.
>>
>> "info/precious" might be a better name
>
> The above is only about the precedence order and is not about introducing
> the new "precious" class at all.
The way I see how info/exclude-override helps keep (ignored but)
precious files is it un-ignores files that are ignored by info/exclude
and .gitignore. But if we go that way, then git-add will also
un-ignore precious files, allowing users to add them in-tree by
mistake.
>>> In the longer term, we should carefully determine if we need "precious" in
>>> the first place. The last time this was brought up there were people who
>>> argued they are OK with having to remove the ignored file by hand when
>>> checking out another branch (i.e. we switch the semantics of "ignored" so
>>> that they are "not tracked but all precious").
>>>
>>> I think it matters in two cases.
>>>
>>> (1) If you change an untracked "cruft" file on branch A into a directory
>>> with tracked files in it on another branch B. If you are on branch A,
>>> have that "cruft" file (perhaps it is a build product after running
>>> "make"), and try to checkout branch B, such an updated "git checkout"
>>> will start erroring out telling you that "cruft" will be lost.
>>>
>>> (2) If you have a directory on branch A, underneath of which there are
>>> untracked "cruft" files (e.g. think "build/" directory that is full
>>> of "*.o" files and ".gitignore" to mark object files as ignored but
>>> is otherwise empty), and another branch B that has the same path as a
>>> file. If you are on branch A, have "cruft" files in that directory,
>>> and try to checkout branch B, such an updated "git checkout" will
>>> start erroring out telling you that "cruft" will be lost.
>>
>> I think we should do this regardless precious being added or not.
>
> Because (see below)?
Because it may potentially lose user's changes. Assume file "A" is
tracked and also ignored. Users may make some changes in A, then move
HEAD away without touching worktree, now HEAD does not see "A" as
tracked any more. If we switch to a branch that has A tracked, git may
override A and wipe our user changes in that file. In short, if a file
is tracked (either in source or target in 2-way merge) then we ignore
excluded() result on that file.
>>> If people are OK with such a behaviour, we can do without "precious".
>>
>> What about git-clean to remove ignored but not precious files?
>
(git clean without -x snipped because I was talking about -x)
>
> "clean -x" is more subtle. It has been a way to say "Remove cruft the
> usual way, and in addition, remove the expendable build products, just
> like 'make clean' _should_ do, but I do not trust my Makefile". If we
> introduced "precious", it would be very clear what it should do---even
> with "-x" precious files should be kept. But if we don't and just try to
> get away by changing the semantics of "ignored", they will still need to
> be removed, so we won't really get the "precious".
>
> The conclusion from this is that it is a mistake to change the semantics
> of "ignored" from the current "untracked and expendable if needed" if the
> purpose of that change is to avoid introducing the new "precious" class.
>
> I don't care too much about it, as I do not use "git clean -x" myself ;-)
> but that wouldn't stop others from think about the issue and try to come
> up with a good solid design.
I don't use "git clean -x" myself either. This is just some input to
the discussion and true users are supposed to speak up. The point I
want to make is, if users really want the ability remove non-precious
ignored files, then we may need to add the new "precious" class that
(and you seem to reach the same conclusion).
--
Duy
^ permalink raw reply
* 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
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