On Wed, Mar 27, 2013 at 9:17 AM, Junio C Hamano wrote:
> To be paranoid, you may want to set transfer.fsckObjects to true,
> perhaps in your ~/.gitconfig.
do we have any numbers on the overhead of this?
Even a "guesstimate" will do...
--
To unsubscribe from this list: send the line "unsubscribe
In checkout_paths() we do this
- for all updated items, call match_pathspec
- for all items, call match_pathspec (inside unmerge_cache)
- for all items, call match_pathspec (for showing "path .. is unmerged)
- for updated items, call match_pathspec and update paths
That's a lot of duplicate m
Sebastian Schuberth wrote:
> This originates from an msysgit pull request, see:
>
> https://github.com/msysgit/git/pull/58
>
> Signed-off-by: Eric Wieser
> Signed-off-by: Sebastian Schuberth
Thanks, looks obviously correct.
Signed-off-by: Eric Wong
> diff --git a/perl/Git/SVN/Ra.pm b/perl/
On Wed, Mar 27, 2013 at 10:57 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> How about this? git_check_attr() now takes dtype as an argument
>> and the caller must not add the trailing slash. This could be
>> split into two patches, one for git_check_attr prototype change,
>> and the other
Duy Nguyen writes:
> How about this? git_check_attr() now takes dtype as an argument
> and the caller must not add the trailing slash. This could be
> split into two patches, one for git_check_attr prototype change,
> and the other the real meat.
"git check-attr" fundamentally cannot know, but
Rich Fromm writes:
> Jeff King wrote
>> Fundamentally the problem is
>> that the --local transport is not safe from propagating corruption, and
>> should not be used if that's a requirement.
>
> I've read Jeff Mitchell's blog post, his update, relevant parts of the
> git-clone(1) man page, and a
Currently, if user tried to access a git repository via HTTP and it
fails because the user's permission is not enough to access the
repository, git client tells that http request failed and the error
was 403 forbidden.
But It is not enough for user to understand why it fails, especially
if the use
On Wed, Mar 27, 2013 at 1:49 AM, Jeff King wrote:
> On Tue, Mar 26, 2013 at 11:39:28AM -0700, Junio C Hamano wrote:
>
>> The function takes two strings (pathname and basename) as if they
>> are independent strings, but in reality, the latter is always
>> pointing into a substring in the former.
>>
On Wed, Mar 27, 2013 at 4:33 AM, Jeff King wrote:
> Hmm. match_pathname does have this:
>
> /*
> * baselen does not count the trailing slash. base[] may or
> * may not end with a trailing slash though.
> */
> if (pathlen < baselen + 1 ||
> (ba
Hi,
Rich Fromm wrote:
>The host executing the clone
> command is different than the the host on which the remote repository lives,
> and I am using ssh as a transport protocol. If there is corruption, can I
> or can I not expect the clone operation
qOn Tue, Mar 26, 2013 at 11:39:27AM -0700, Junio C Hamano wrote:
> So here is an attempt to fix the unintended regression, on top of
> 9db9eecfe5c2 (attr: avoid calling find_basename() twice per path,
> 2013-01-16). It consists of four patches.
Not that I disagree with this. Just wanted to see ho
On Tue, Mar 26, 2013 at 03:33:40PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So I think your series is the right direction, but we would want to
> > factor out the allocation code and use it from match_pathname, as well.
>
> I am deep into today's integration cycle, so perhaps in t
On Tue, Mar 26, 2013 at 03:32:59PM -0700, Jonathan Nieder wrote:
> > +static const char junk_leave_repo_msg[] =
> > +N_("The remote repository was cloned successfully, but there was\n"
> > + "an error checking out the HEAD branch. The repository has been left
> > in\n"
> > + "place but the wo
Jeff King wrote
> Fundamentally the problem is
> that the --local transport is not safe from propagating corruption, and
> should not be used if that's a requirement.
I've read Jeff Mitchell's blog post, his update, relevant parts of the
git-clone(1) man page, and a decent chunk of this thread, an
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
Jeff King writes:
> So I think your series is the right direction, but we would want to
> factor out the allocation code and use it from match_pathname, as well.
I am deep into today's integration cycle, so perhaps in the meantime
you can help with a follow-up patch ;-)?
--
To unsubscribe from t
Jeff King wrote:
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -377,10 +377,40 @@ static void remove_junk(void)
> static const char *junk_work_tree;
> static const char *junk_git_dir;
> static pid_t junk_pid;
> +enum {
> + JUNK_LEAVE_NONE,
> + JUNK_LEAVE_REPO,
> + JUNK_LEAVE_
On Tue, Mar 26, 2013 at 07:53:42AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Mar 26, 2013 at 3:26 AM, Jeff King wrote:
> > static void update_remote_refs(const struct ref *refs,
> >const struct ref *mapped_refs,
> >const struct r
On Tue, Mar 26, 2013 at 02:40:57PM -0700, Junio C Hamano wrote:
> > I think the "leave the data behind" fix may be to just set "junk_pid =
> > 0" a little sooner in cmd_clone (i.e., before checkout()). Then we
> > would still die, but at least leave the fetched objects intact.
>
> Yeah, perhaps,
I have a branch for which I have made 0 (nada) changes. I did the
following:
$git pull --rebase --no-stat -v --progress origin mybranch
I get the following
U java/Profile.java
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git a
Eric Kom writes:
> Good day,
>
> Please how can I change the committer username from system default to
> personalize?
Quoting from a very early part of
http://git-htmldocs.googlecode.com/git/gittutorial.html
It is a good idea to introduce yourself to Git with your name and
public email ad
Matt McClure writes:
> I've read Documentation/SubmittingPatches, followed some of the
> discussion on this list, and looked over some of the recent commit
> history. I'm impressed by the strong culture of review that produces
> readable patches and commit messages, but I think there are some gap
On Tue, Mar 26, 2013 at 09:59:42PM -, Philip Oakley wrote:
> Which way does `git bundle file.bundl --all` perform after the changes
> for both the 'transport' checking and being reliable during updates.
Bundles are treated at a fairly low level the same as a remote who
provides us a particula
From: "Jeff King"
Sent: Tuesday, March 26, 2013 4:55 PM
On Tue, Mar 26, 2013 at 09:43:01AM -0400, Jeff Mitchell wrote:
On Mon, Mar 25, 2013 at 4:07 PM, Jeff King wrote:
> On Mon, Mar 25, 2013 at 12:32:50PM -0400, Jeff Mitchell wrote:
>> For commit corruptions, the --no-hardlinks, non --mirror
Jeff King writes:
> The slowdown is really quite terrible if you try "git clone --bare
> linux-2.6.git". Even with this, the local-clone case already misses blob
> corruption. So it probably makes sense to restrict it to just the
> non-local clone case, which already has to do more work.
Probabl
From: "Duy Nguyen"
Sent: Tuesday, March 26, 2013 9:48 AM
On Tue, Mar 26, 2013 at 08:02:30AM -, Philip Oakley wrote:
>> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
>> GIT_DIR is explicitly set.
>
> And it *WILL* be that way til the end of time. Unless you are at
> the
Jeff King writes:
> When clone is populating the working tree, it ignores the
> return status from unpack_trees; this means we may report a
> successful clone, even when the checkout fails.
>
> When checkout fails, we may want to leave the $GIT_DIR in
> place, as it might be possible to recover t
Jeff King writes:
> Subject: [PATCH] streaming_write_entry: propagate streaming errors
>
> When we are streaming an index blob to disk, we store the
> error from stream_blob_to_fd in the "result" variable, and
> then immediately overwrite that with the return value of
> "close". That means we cat
On Tue, Mar 26, 2013 at 03:05:58PM -0400, Jeff King wrote:
> On Tue, Mar 26, 2013 at 11:39:30AM -0700, Junio C Hamano wrote:
>
> > A similar adjustment for match_pathname() might be needed, but I
> > didn't look into it.
>
> I notice that match_pathname takes _two_ lengths for the pattern: the
>
Good day,
Please how can I change the committer username from system default to
personalize?
--
Kind Regards
Eric Kom
System Administrator & Programmer - Metropolitan College
_
/ You are scrupulously honest, frank, and \
| straightforward. Therefore y
On Tue, Mar 26, 2013 at 01:49:10PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I timed this doing "git archive HEAD" on webkit.git before and after. It
> > actually ended up not mattering much (I think because it is only the
> > directories which are affected, not each individually pa
Jeff King writes:
> We call read_istream, but never check its return value for
> errors. This can lead to us looping infinitely, as we just
> keep trying to write "-1" bytes (and we do not notice the
> error, as we simply check that write_in_full reports the
> same number of bytes we fed it, whic
This originates from an msysgit pull request, see:
https://github.com/msysgit/git/pull/58
Signed-off-by: Eric Wieser
Signed-off-by: Sebastian Schuberth
---
perl/Git/SVN/Ra.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 049c9
I've read Documentation/SubmittingPatches, followed some of the
discussion on this list, and looked over some of the recent commit
history. I'm impressed by the strong culture of review that produces
readable patches and commit messages, but I think there are some gaps
in my understanding of the pr
On Tue, Mar 26, 2013 at 04:52:02PM -0400, Matt McClure wrote:
> On Mon, Mar 25, 2013 at 5:44 PM, John Keeping wrote:
> > Instead of copying unconditionally when the files differ, create and
> > index from the working tree files and only copy the temporary file back
> > if it was modified and the w
On Mon, Mar 25, 2013 at 5:44 PM, John Keeping wrote:
> Instead of copying unconditionally when the files differ, create and
> index from the working tree files and only copy the temporary file back
> if it was modified and the working tree file was not. If both files
> have been modified, print a
Jeff King writes:
> I timed this doing "git archive HEAD" on webkit.git before and after. It
> actually ended up not mattering much (I think because it is only the
> directories which are affected, not each individually path, so it's a
> much smaller number than you'd think). The best-of-five tim
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson writes:
> > I would propose a new extension, 'CONF', to handle conflict data,
> > differing from the stage >0 entries in the index in that this
> > extension tracks the conflicting file across names if the underlying
> > merge engi
On Tue, Mar 26, 2013 at 02:55:59PM -0400, Jeff King wrote:
> > * Otherwise, make sure we use only the counted part of the strings
> >when calling fnmatch_icase(). Because these counted strings are
> >full strings most of the time, avoid unnecessary allocation.
>
> I think this is OK, wi
Jeff King wrote:
> On Tue, Mar 26, 2013 at 01:21:42PM -0700, Jonathan Nieder wrote:
>> If we want this warning, would something like the following do?
>>
>> warning: You have set GIT_DIR without setting GIT_WORK_TREE
>> hint: In this case, GIT_WORK_TREE defaults to '.'
>> hint: To
On Tue, Mar 26, 2013 at 01:21:42PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -437,6 +437,23 @@ const char *read_gitfile(const char *path)
> > return path;
> > }
> >
> > +static const char warn_implicit_work_tree_msg[] =
> > +N_("You have
Jeff King wrote:
> --- a/setup.c
> +++ b/setup.c
> @@ -437,6 +437,23 @@ const char *read_gitfile(const char *path)
> return path;
> }
>
> +static const char warn_implicit_work_tree_msg[] =
> +N_("You have set GIT_DIR (or used --git-dir) without specifying\n"
> + "a working tree. In Git
Jeff King wrote:
> --- a/environment.c
> +++ b/environment.c
> @@ -194,6 +194,7 @@ void set_git_work_tree(const char *new_work_tree)
> }
> git_work_tree_initialized = 1;
> work_tree = xstrdup(real_path(new_work_tree));
> + setenv(GIT_WORK_TREE_ENVIRONMENT, work_tree, 1);
> }
Follow-through on the deprecation warning added by the last
commit.
We can drop all of the IMPLICIT_WORK_TREE code now, since
we default to that case.
Signed-off-by: Jeff King
---
This would obviously come much later than patch 2, in Git 2.0 or
whatever.
But in case anyone did not read the disc
It can be surprising to some users that pointing GIT_DIR to
a ".git" directory does not use the working tree that
surrounds the .git directory, but rather uses the current
working directory as the working tree.
Git has always worked this way, and for the most part it has
not been a big problem. H
If we end up in a sub-process where GIT_WORK_TREE is not set
but GIT_DIR is, we assume the current directory is the root
of the working tree. Since future patches will change that
assumption, let's defensively start setting GIT_WORK_TREE
explicitly.
Signed-off-by: Jeff King
---
I didn't test this
On Tue, Mar 26, 2013 at 11:20:58AM -0700, Junio C Hamano wrote:
> When you are in ~/mail/subdir, because GIT_DIR alone does not give
> you to specify where the root-level of the working tree is, you had
> to "cd .." before running "GIT_DIR=~/git/mail.git git ...". By
> setting GIT_WORK_TREE to po
On Tue, Mar 26, 2013 at 03:35:39PM -0400, Jeff King wrote:
> I note that we do not actually check that contents != NULL after calling
> read_sha1_file, either (nor that sha1_object_info does not return an
> error). I suspect cat-file could segfault under the right conditions.
Oh nevermind, we do.
On Tue, Mar 26, 2013 at 07:20:11PM +, Ramsay Jones wrote:
> After commit cbfd5e1c ("drop some obsolete "x = x" compiler warning
> hacks", 21-03-2013) removed a gcc specific hack, older versions of
> gcc now issue an "'contents' might be used uninitialized" warning.
> In order to suppress the w
On Tue, Mar 26, 2013 at 10:53:48AM +0100, Johannes Sixt wrote:
> Am 3/26/2013 10:31, schrieb John Keeping:
> > On Tue, Mar 26, 2013 at 09:38:42AM +0100, Johannes Sixt wrote:
> > The last test does result in /tmp filling up with temporary directories
> > though, it would be good if the test could cl
On Tue, Mar 26, 2013 at 07:09:44PM +, Ramsay Jones wrote:
> Commit cbfd5e1c ("drop some obsolete "x = x" compiler warning hacks",
> 21-03-2013) removed a gcc hack that suppressed an "might be used
> uninitialized" warning issued by older versions of gcc.
>
> However, commit 3aa99df8 ('fast-im
Edward Thomson writes:
> I would propose a new extension, 'CONF', to handle conflict data, differing
> from the stage >0 entries in the index in that this extension tracks the
> conflicting file across names if the underlying merge engine has support
> for renames.
>
> I made an attempt to keep t
Commit cbfd5e1c ("drop some obsolete "x = x" compiler warning hacks",
21-03-2013) removed a gcc hack that suppressed an "might be used
uninitialized" warning issued by older versions of gcc.
However, commit 3aa99df8 ('fast-import: clarify "inline" logic in
file_change_m', 21-03-2013) addresses an
After commit cbfd5e1c ("drop some obsolete "x = x" compiler warning
hacks", 21-03-2013) removed a gcc specific hack, older versions of
gcc now issue an "'contents' might be used uninitialized" warning.
In order to suppress the warning, we simply initialize the variable
to NULL in it's declaration.
Hi Junio,
I had prepared 3 patches, but I noticed this afternoon that
the warning in transport.c has already been fixed in maint.
These were built on the tip of master as of saturday evening
(master @ 7b592fad).
Just FYI, as of saturday, Jeff's patches in maint/master had
removed 40 warnings from
On 26 March 2013 18:48, Jeff King wrote:
> On Tue, Mar 26, 2013 at 06:20:09PM +0100, demerphq wrote:
>
>> Seconded. At $work lots of people started asking anxious questions
>> about this. It was suggested it is a potential security hole, although
>> I am not sure I agree, but the general idea bein
On Tue, Mar 26, 2013 at 11:39:31AM -0700, Junio C Hamano wrote:
> From: Jeff King
>
> Prior to v1.8.1.1, with:
>
> git init
> echo content >foo &&
> mkdir subdir &&
> echo content >subdir/bar &&
> echo "subdir export-ignore" >.gitattributes
> git add . &&
> git commit -m one &&
>
On Tue, Mar 26, 2013 at 11:39:30AM -0700, Junio C Hamano wrote:
> A similar adjustment for match_pathname() might be needed, but I
> didn't look into it.
I notice that match_pathname takes _two_ lengths for the pattern: the
nowildcardlen (called "prefix", and the full patternlen). But the first
t
On Tue, Mar 26, 2013 at 11:39:29AM -0700, Junio C Hamano wrote:
> The function takes two counted strings ( and
> ) as parameters, together with prefix (the
> length of the prefix in pattern that is to be matched literally
> without globbing against the basename) and EXC_* flags that tells it
> how
On Tue, Mar 26, 2013 at 11:39:28AM -0700, Junio C Hamano wrote:
> The function takes two strings (pathname and basename) as if they
> are independent strings, but in reality, the latter is always
> pointing into a substring in the former.
>
> Clarify this relationship by expressing the latter as
From: Jeff King
Prior to v1.8.1.1, with:
git init
echo content >foo &&
mkdir subdir &&
echo content >subdir/bar &&
echo "subdir export-ignore" >.gitattributes
git add . &&
git commit -m one &&
git archive HEAD | tar tf -
the resulting archive would contain only "foo" and ".gitat
The function takes two counted strings ( and
) as parameters, together with prefix (the
length of the prefix in pattern that is to be matched literally
without globbing against the basename) and EXC_* flags that tells it
how to match the pattern against the basename.
However, it did not pay attent
The function is given a string that ends with a slash to signal that
the path is a directory to make sure that a pattern that ends with a
slash (i.e. MUSTBEDIR) can tell directories and non-directories
apart. However, the pattern itself (pat->pattern and
pat->patternlen) that came from such a MUST
The function takes two strings (pathname and basename) as if they
are independent strings, but in reality, the latter is always
pointing into a substring in the former.
Clarify this relationship by expressing the latter as an offset into
the former.
Signed-off-by: Junio C Hamano
---
attr.c | 19
So here is an attempt to fix the unintended regression, on top of
9db9eecfe5c2 (attr: avoid calling find_basename() twice per path,
2013-01-16). It consists of four patches.
The first patch is not essential to the fix, but I think it
clarifies what is going on in this codepath.
The second patch
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson writes:
>
> > I would propose that we store the data about the file in conflict as
> > it occurred through the renames. For example, in a rename 1->2
> > conflict where A was renamed to both B and C, you would have a single
> > co
Jeff King writes:
> Yes, setting GIT_DIR but not GIT_WORK_TREE has always been a valid way
> to work on a repository where you do not want the working tree polluted
> with your .git file. It's not a common setup, but people do use it.
> E.g., you might keep ~/mail as a git repo, but do not want t
On Tue, Mar 26, 2013 at 06:20:09PM +0100, demerphq wrote:
> Seconded. At $work lots of people started asking anxious questions
> about this. It was suggested it is a potential security hole, although
> I am not sure I agree, but the general idea being that if you could
> manage to set this var in
On Tue, Mar 26, 2013 at 06:06:17PM +0100, Richard Weinberger wrote:
> >We could, but that would break the existing behavior for other people
> >(and I assume you mean "when GIT_WORK_TREE is not set at all", as I
> >would think GIT_WORK_TREE=. is explicit enough).
>
> Is there a valid use case to
On 26 March 2013 18:06, Richard Weinberger wrote:
> P.s: I've told this story to some friends and co-workers which use git like
> me very day.
> All of them were shocked about the behavior of git-clean and GIT_DIR.
Seconded. At $work lots of people started asking anxious questions
about this. It
Am 26.03.2013 15:56, schrieb Jeff King:
On Tue, Mar 26, 2013 at 02:07:44PM +0100, Richard Weinberger wrote:
Should this important warning be part of the git(1) documentation on
the environment variables (and possibly other places) given the
consequences of this case? It wasn't something
I'd app
Am 26.03.2013 08:57, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> And leaving aside 'add', there are tons of submodules out there
>> which were cloned with older Git who have their .git directory
>> inside the work tree. So a new subcommand (or at least a helper
>> script in contrib) to r
On Tue, Mar 26, 2013 at 09:43:01AM -0400, Jeff Mitchell wrote:
> On Mon, Mar 25, 2013 at 4:07 PM, Jeff King wrote:
> > On Mon, Mar 25, 2013 at 12:32:50PM -0400, Jeff Mitchell wrote:
> >> For commit corruptions, the --no-hardlinks, non --mirror case refused
> >> to create the new repository and ex
On 03/26/2013 05:26 PM, Junio C Hamano wrote:
> Sebastian Götte writes:
>
>> On 03/26/2013 02:46 AM, Junio C Hamano wrote:> Sebastian Götte
>> writes:
Rebased it onto the current 'master'. The second patch fixes that the GPG
status parser ignores the first line of GPG status output (t
Ramkumar Ramachandra writes:
> Apart from the implementation glitches, I don't like the design;
> submodules don't compose well:
>
> 1. There's an inherent asymmetry between the superproject and each of
> the subprojects, because the superproject owns all the object stores.
> Why is it absolutely
Jeff King writes:
> On Tue, Mar 26, 2013 at 04:48:44PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> Something like this, maybe?
>>
>> -- 8< --
>> Subject: [PATCH] git.txt: document the implicit working tree setting with
>> GIT_DIR
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> Documentation/
Sebastian Götte writes:
> On 03/26/2013 02:46 AM, Junio C Hamano wrote:> Sebastian Götte
> writes:
>>> Rebased it onto the current 'master'. The second patch fixes that the GPG
>>> status parser ignores the first line of GPG status output (that would be
>>> caught
>>> by the new merge signatur
The documentation for verify-pack states under the "-s, --stat-only" option,
that "With --verbose, list of objects is also shown.". However, this seems
to not be true in either 1.8.2 or 1.7.11.4, the two versions I have readily
at hand. I'm guessing this might be a documentation error (and is proba
Nguyễn Thái Ngọc Duy writes:
> I think the fix is something like this. There is still one thing I'd
> like to do: make this code not rely on NUL for terminating the
> patterns. That should remove the ugly "p[len] = '\0'" in
> prepare_attr_stack() 4/4 and and the reallocation in add_exclude() (in
On Tue, Mar 26, 2013 at 04:48:44PM +0700, Nguyen Thai Ngoc Duy wrote:
> Something like this, maybe?
>
> -- 8< --
> Subject: [PATCH] git.txt: document the implicit working tree setting with
> GIT_DIR
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/git.txt | 2 ++
> 1 file changed
On Tue, Mar 26, 2013 at 02:07:44PM +0100, Richard Weinberger wrote:
> >Should this important warning be part of the git(1) documentation on
> >the environment variables (and possibly other places) given the
> >consequences of this case? It wasn't something
> >I'd appreciated from a simple reading.
Dan Bornstein writes:
> In particular, it can get called with four arguments if you happen to
> be referring to a repo using the ssh:// scheme with a non-default port
> number.
>
> Signed-off-by: Dan Bornstein
> ---
> Documentation/git.txt |9 ++---
> 1 files changed, 6 insertions(+), 3
On Mon, Mar 25, 2013 at 4:07 PM, Jeff King wrote:
> On Mon, Mar 25, 2013 at 12:32:50PM -0400, Jeff Mitchell wrote:
>> For commit corruptions, the --no-hardlinks, non --mirror case refused
>> to create the new repository and exited with an error code of 128. The
>> --no-hardlinks, --mirror case spe
Am 26.03.2013 09:02, schrieb Philip Oakley:
From: "Junio C Hamano"
Sent: Monday, March 25, 2013 10:06 PM
Jonathan Nieder writes:
Richard Weinberger wrote:
In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
changing the
current working directory all the time.
Yeah,
Junio C Hamano writes:
> Thomas Rast writes:
>
>> The delta base cache lookup and test were shared. Refactor them;
>> we'll need both parts again. Also, we'll use the clearing routine
>> later.
>>
>> Signed-off-by: Thomas Rast
>> ---
>
> Looks like a very straight-forward rewrite.
>
> The onl
Expand %G? in pretty format strings to 'N' in case of no GPG signature
and 'U' in case of a good but untrusted GPG signature in addition to
the previous 'G'ood and 'B'ad. This eases writing anyting parsing
git-log output.
Signed-off-by: Sebastian Götte
---
Documentation/pretty-formats.txt | 3 ++
When --verify-signatures is specified, abort the merge in case a good
GPG signature from an untrusted key is encountered.
Signed-off-by: Sebastian Götte
---
builtin/merge.c| 2 ++
commit.c | 2 ++
commit.h | 9 +---
When --verify-signatures is specified on the command-line of git-merge
or git-pull, check whether the commits being merged have good gpg
signatures and abort the merge in case they do not. This allows e.g.
auto-deployment from untrusted repo hosts.
Signed-off-by: Sebastian Götte
---
Documentatio
Signed-off-by: Sebastian Götte
---
commit.c| 59 +
commit.h| 9 +++
gpg-interface.h | 8 ++
pretty.c| 75 -
4 files changed, 81 insertions(+), 70 deletions(-)
dif
Signed-off-by: Sebastian Götte
---
commit.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index 1aeb17a..533727c 100644
--- a/commit.c
+++ b/commit.c
@@ -1027,8 +1027,8 @@ static struct {
char result;
const char *check;
} signature
On 03/26/2013 02:46 AM, Junio C Hamano wrote:> Sebastian Götte
writes:
>> Rebased it onto the current 'master'. The second patch fixes that the GPG
>> status parser ignores the first line of GPG status output (that would be
>> caught
>> by the new merge signature verification test case).
>
> Th
Am 3/26/2013 10:31, schrieb John Keeping:
> On Tue, Mar 26, 2013 at 09:38:42AM +0100, Johannes Sixt wrote:
>> One question though: Do I understand correctly that the temporary
>> directories are leaked in the case of an "edit conflict"? If so, is it
>> worth a warning for the user to clean up the g
On Tue, Mar 26, 2013 at 08:02:30AM -, Philip Oakley wrote:
> >> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
> >> GIT_DIR is explicitly set.
> >
> > And it *WILL* be that way til the end of time. Unless you are at
> > the top level of your working tree, you are supposed t
On Tue, Mar 26, 2013 at 09:38:42AM +0100, Johannes Sixt wrote:
> Am 3/25/2013 22:44, schrieb John Keeping:
> > After running the user's diff tool, git-difftool will copy any files
> > that differ between the working tree and the temporary tree. This is
> > useful when the user edits the file in th
On Mon, Mar 25, 2013 at 02:50:38PM -0700, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > Am 3/25/2013 11:35, schrieb John Keeping:
> >> On Mon, Mar 25, 2013 at 08:26:52AM +0100, Johannes Sixt wrote:
> >>> The series looks good, but I can't test it because it does not apply
> >>> anywhere her
Sorry about the repeat Junio, I meant to hit "Reply to All".
On Mon, Mar 25, 2013 at 5:44 PM, Junio C Hamano wrote:
[snip]
> Your patch makes me wonder if
>
> test -n "$TERM_PROGRAM"
>
> without any SECURITYSESSIONID or explicit program name checks should
> suffice, though.
So, after dow
Forgot to mention: The patch passes t7800 on Windows.
Thanks,
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 3/25/2013 22:44, schrieb John Keeping:
> After running the user's diff tool, git-difftool will copy any files
> that differ between the working tree and the temporary tree. This is
> useful when the user edits the file in their diff tool but is wrong if
> they edit the working tree file while e
From: "Junio C Hamano"
Sent: Monday, March 25, 2013 10:06 PM
Jonathan Nieder writes:
Richard Weinberger wrote:
In my scripts I'm setting GIT_DIR to use git-fetch and git-reset
without changing the
current working directory all the time.
Yeah, for historical reasons GIT_WORK_TREE defaults
Jens Lehmann wrote:
> Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra:
>> Doesn't that sound horribly crippled to you? Is there any advantage
>> to leaving the .git directory inside the submodule? Isn't it always
>> better to relocate it?
>
> It's not crippled at all, that is just the way it wa
1 - 100 of 101 matches
Mail list logo
