Hi,
the
```sh
git add config_real.xml
git stash -k
git reset
```
is not very well suited because the -k option to keep the index.
However, the index will still be put inside the stash.
So what you propose is equivalent to:
```sh
git stash
git stash apply stash@\{0\}
git checkout --config
Hi Brian,
On 2015-04-23 02:06, brian m. carlson wrote:
> + tortoiseplink = tplink == ssh ||
> + (tplink && is_dir_sep(tplink[-1]));
Maybe have a helper function here? Something like `basename_matches(const char
*path, const char *b
On Wed, Apr 22, 2015 at 4:30 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
+action = "noop" / "ls-remote" / "fetch" / "push" /
"fetch-shallow"
>> ...
>>> If we are going in this "in-protocol message switches the service"
>>> route, we should also support "archive" as on
On 04/22/2015 09:12 PM, Patrick Sharp wrote:
Johannes,
You’re correct, looking back over it, I was pretty vague.
In truth, we are not using Windows OR putty at all. Running git on an Ubuntu
system, but we are setting the GIT_SSH environment variable to point to a shell
script to use.
Upon a
On Wed, Apr 22, 2015 at 3:32 PM, Jens Lehmann wrote:
> ...
>> But it is unclear if we should still do (2) when "subrepo/.git" is
>> no longer there. That has to be done manually and it may be an
>> indication that is clear enough that the end user wants the
>> directory to be a normal directory w
On Wed, Apr 22, 2015 at 7:44 PM, Michael Haggerty wrote:
> I think what you are looking for is
>
> return any(r.match(branch) for r in branches)
Yup, thats exactly what I wanted. I'll submit an updated patch
> I was also wondering why you decided to support comma-separated lists of
> regexp
On Wed, Apr 22, 2015 at 4:24 PM, brian m. carlson
wrote:
> Signed-off-by: brian m. carlson
> ---
> refs.c | 44 ++--
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 81a455b..522d15d 100644
> --- a/refs.c
> +++ b
The code path used in git_connect pushed the majority of the SSH
connection code into an else block, even though the if block returns.
Simplify the code by eliminating the else block, as it is unneeded.
Signed-off-by: Jeff King
Signed-off-by: brian m. carlson
---
connect.c | 42
The git_connect function has code to handle plink and tortoiseplink
specially, as they require different command line arguments from
OpenSSH. However, the match was done by checking for "plink"
case-insensitively in the string, which led to false positives when
GIT_SSH contained "uplink". Improve
Stefan Beller writes:
>>> +action = "noop" / "ls-remote" / "fetch" / "push" /
>>> "fetch-shallow"
> ...
>> If we are going in this "in-protocol message switches the service"
>> route, we should also support "archive" as one of the actions, no?
>> Yes, I know you named the document "pac
To allow piecemeal conversion of the for_each_*_ref functions, introduce
an additional typedef for a callback function that takes struct
object_id * instead of unsigned char *. Provide an extra field in
struct ref_entry_cb for this callback and ensure at most one is set at a
time. Temporarily suf
Signed-off-by: brian m. carlson
---
refs.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index 9e61b32..6c04189 100644
--- a/refs.c
+++ b/refs.c
@@ -10,7 +10,7 @@ struct ref_lock {
char *ref_name;
char *orig_ref_name
Now that all the callers of handle_refs are gone, rename handle_refs_oid
to handle_refs and update the callers accordingly.
Signed-off-by: brian m. carlson
---
revision.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/revision.c b/revision.c
index 825
Remove the temporary for_each_ref_in_oid function and update the users
of it. Convert the users of for_each_branch_ref and
for_each_remote_ref (which use for_each_ref_in under the hood) as well.
Signed-off-by: brian m. carlson
---
bisect.c| 8
builtin/rev-parse.c | 10
Convert head_ref_namespaced and for_each_namespaced_ref to use struct
object_id. Update the various callbacks to use struct object_id
internally as well.
Signed-off-by: brian m. carlson
---
http-backend.c | 14 +++---
refs.c | 12 ++--
refs.h | 4 ++--
upload-pa
Signed-off-by: brian m. carlson
---
refs.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/refs.c b/refs.c
index 81a455b..522d15d 100644
--- a/refs.c
+++ b/refs.c
@@ -156,7 +156,7 @@ struct ref_value {
* null. If REF_ISS
While these functions were needed during the intermediate steps of
converting for_each_ref and friends to struct object_id, there is no
longer any need to have these wrapper functions. Update each of the
functions that the wrapper functions call and remove the _oid wrapper
functions themselves.
S
Update callbacks to take the proper parameters and use struct object_id
elsewhere in the callbacks.
Signed-off-by: brian m. carlson
---
builtin/replace.c | 14 +++---
refs.c| 4 ++--
refs.h| 2 +-
replace_object.c | 4 ++--
4 files changed, 12 insertions(+), 1
Convert head_ref and head_ref_submodule to use struct object_id.
Introduce some wrappers in some of the callers to handle
incompatibilities between each_ref_fn and each_ref_fn_oid.
Signed-off-by: brian m. carlson
---
builtin/show-ref.c | 7 ++-
log-tree.c | 7 ++-
reachable.c
each_ref_fn is no longer used, so rename each_ref_fn_oid to each_ref_fn.
Update the documentation to note the change in function signature.
Signed-off-by: brian m. carlson
---
Documentation/technical/api-ref-iteration.txt | 2 +-
refs.c| 48 +-
Signed-off-by: brian m. carlson
---
builtin/fsck.c | 2 +-
builtin/reflog.c | 4 ++--
refs.c | 10 +-
refs.h | 2 +-
revision.c | 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 85238a7..6659f81 1
Convert callbacks to use struct object_id internally as well.
Signed-off-by: brian m. carlson
---
builtin/branch.c | 4 ++--
builtin/describe.c | 12 ++--
builtin/for-each-ref.c | 4 ++--
builtin/fsck.c | 16
refs.c | 10 +-
re
Convert for_each_ref, for_each_glob_ref, and for_each_glob_ref_in to use
struct object_id, as the latter two call the former with the function
pointer they are provided.
Convert callers to refer to properly-typed functions. Convert uses of
the constant 20 to GIT_SHA1_RAWSZ. Where possible, conve
Convert the callers as well.
Signed-off-by: brian m. carlson
---
refs.c | 4 ++--
refs.h | 2 +-
revision.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 7a8b579..68d0af8 100644
--- a/refs.c
+++ b/refs.c
@@ -2014,9 +2014,9 @@ int for_each_re
do_for_each_ref was unused due to previous patches, so rename
do_for_each_ref_oid to do_for_each_ref. Similarly, remove the unused fn
member from struct ref_entry in favor of renaming the fn_oid member.
Signed-off-by: brian m. carlson
---
refs.c | 43 +++
This is a conversion of parts of refs.c to use struct object_id.
refs.c, and the for_each_ref series of functions explicitly, is the
source for many instances of object IDs in the codebase. Therefore, it
makes sense to convert this series of functions to provide a basis for
further conversions.
Convert for_each_ref_in_submodule and all of its caller. Introduce two
temporary wrappers in revision.c to handle the incompatibilities between
each_ref_fn and each_ref_fn_oid.
Signed-off-by: brian m. carlson
---
refs.c | 10 +-
refs.h | 8
revision.c | 28 +
On Wed, Apr 22, 2015 at 10:24:55PM +, brian m. carlson wrote:
> On Wed, Apr 22, 2015 at 06:00:54PM -0400, Jeff King wrote:
> > Yeah, that looks right to me. You might want to represent the "are we
> > tortoise" check as a separate flag, though, and reuse it a few lines
> > later.
>
> Sounds l
Am 22.04.2015 um 21:58 schrieb Junio C Hamano:
Jens Lehmann writes:
Am 21.04.2015 um 23:08 schrieb Junio C Hamano:
I looked at the test script update. The new test does (I am
rephrasing to make it clearer):
mkdir -p dir/ectory
git init dir/ectory ;# a new directory inside top-l
On Wed, Apr 22, 2015 at 06:00:54PM -0400, Jeff King wrote:
> Yeah, that looks right to me. You might want to represent the "are we
> tortoise" check as a separate flag, though, and reuse it a few lines
> later.
Sounds like a good idea. I'll send a more formal patch a bit later
today.
> Also, not
A release candidate Git v2.4.0-rc3 is now available for testing at
the usual places. This hopefully will be the last -rc before the
2.4 final.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.4.0-rc3
On Wed, Apr 22, 2015 at 09:44:45PM +, brian m. carlson wrote:
> On Wed, Apr 22, 2015 at 05:29:04PM -0400, Jeff King wrote:
> > > Perhaps it would be worthwhile to check instead if the text "plink" is
> > > the beginning of string or is preceded by a path separator. That would
> > > give us a
Stefan Saasen writes:
> Anyway, long story short. We're interested to help but I'm not
> entirely sure what that would look like at the moment. Are there
> formed ideas floating around or would you be looking for some form of
> proposal instead?
I am not proposing anything or looking for proposa
On Wed, Apr 22, 2015 at 05:29:04PM -0400, Jeff King wrote:
> > Perhaps it would be worthwhile to check instead if the text "plink" is
> > the beginning of string or is preceded by a path separator. That would
> > give us a bit more confidence that the user is looking for plink, but
> > would still
$GIT_DIR/info/exclude and core.excludesfile (which falls back to
$XDG_HOME/git/ignore) are both ways to override the ignore pattern
lists given by the project in .gitignore files. The former, which
is per-repository personal preference, should take precedence over
the latter, which is a personal p
This is another attempt on enabling large transactions
(large in terms of open file descriptors). We keep track of how many
lock files are opened by the ref_transaction_commit function.
When more than a reasonable amount of files is open, we close
the file descriptors to make sure the transaction c
On Wed, Apr 22, 2015 at 09:19:15PM +, brian m. carlson wrote:
> > Note that I don't think just switching the strcasestr to look for
> > "plink.exe" is right. For one thing, it just punts on the problem (it
> > can still happen, it's just less likely to trigger). But for another,
> > you can ha
On Wed, Apr 22, 2015 at 04:29:10PM -0400, Jeff King wrote:
> I think you want something like:
>
> diff --git a/connect.c b/connect.c
> index 9ae991a..58aad56 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -568,7 +568,8 @@ struct child_process *git_connect(int fd[2], const char
> *url_orig,
>
On 22/04/15 18:11, Junio C Hamano wrote:
Vitor Antunes writes:
The updates introduced in the third revision of these two patches consist only
on updates to the commit messages to better clarify what they implement.
Vitor Antunes (2):
t9801: check git-p4's branch detection with client spec
On Wed, Apr 22, 2015 at 12:57 PM, Thiago Farina wrote:
> On Wed, Apr 22, 2015 at 4:50 PM, Stefan Beller wrote:
>> On Wed, Apr 22, 2015 at 12:38 PM, Thiago Farina wrote:
>>> IMO, sending email is the easiest part.
>>>
>>> The hard begins when you have to edit your patch and resend with the
>
On Wed, Apr 22, 2015 at 02:12:53PM -0500, Patrick Sharp wrote:
> Johannes,
>
> You’re correct, looking back over it, I was pretty vague.
>
> In truth, we are not using Windows OR putty at all. Running git on an Ubuntu
> system, but we are setting the GIT_SSH environment variable to point to a
On Wed, Apr 22, 2015 at 08:50:26PM +0100, Jeremy Harris wrote:
> Installing the git-debuginfo package gave no additional
> information. The symptom does not show on a Fedora 21
> system with git 2.1.0 (and I note that gitk properly
> shows those filenames on f21, and does not on sl6).
>
> Is th
Hello,
I'm using git 2.3.2 with Kerberos for authentication and gito-lite for
authorization.
This works:
$ git clone https://dvl@ repo.example.org/git/testing
Cloning into 'testing'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
My goal: have it work w
On 04/22/2015 09:09 PM, Stefan Beller wrote:
> On Wed, Apr 22, 2015 at 7:11 AM, Michael Haggerty
> wrote:
>>> + if (lock->lk->fd == -1)
>>> + reopen_lock_file(lock->lk);
>>
>> You should check that reopen_lock_file() was successful.
>
> ok
>
>
>>> @@ -3762,6 +3779,10 @@ int ref
On Wed, Apr 22, 2015 at 12:14:08PM -0700, Stefan Beller wrote:
> > FWIW, we already use a magic value of "25 extra" in open_packed_git_1. I
> > don't know if that means the number has been proven in practice, or if
> > it is simply that nobody actually exercises the pack_max_fds code. I
> > suspec
Hi,
I have a git version 1.7.1 running on Scientific Linux 6.
When a filename with UTF-8 is present in a tree-ish the
"git archive" command crashes:
%%
*** buffer overflow detected ***: git terminated
=== Backtrace: =
/lib64/libc.so.6(__fortify_fail+0x37)
Now that the feature has had time to prove itself, and any
topics in flight have had a chance to clean up any broken
&&-chains, we can flip this feature on by default. This
makes one less thing submitters need to configure or check
before sending their patches.
Signed-off-by: Jeff King
---
t/tes
On Wed, Apr 22, 2015 at 12:23:17PM -0700, Jonathan Nieder wrote:
> > And
> > not just for finding binaries; we want to find $(sharedir),
> > etc, the same way. The RUNTIME_PREFIX build knob does this
> > the right way
>
> Makes sense. For
Jens Lehmann writes:
> Am 21.04.2015 um 23:08 schrieb Junio C Hamano:
>
>> I looked at the test script update. The new test does (I am
>> rephrasing to make it clearer):
>>
>> mkdir -p dir/ectory
>> git init dir/ectory ;# a new directory inside top-level project
>> (
>> c
On Wed, Apr 22, 2015 at 4:50 PM, Stefan Beller wrote:
> On Wed, Apr 22, 2015 at 12:38 PM, Thiago Farina wrote:
>>>
>> IMO, sending email is the easiest part.
>>
>> The hard begins when you have to edit your patch and resend with the
>> reviewers' feedback incorporated. For me that is the most tri
On Wed, Apr 22, 2015 at 12:45:21PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Ironically, the message before e0e2a9c actually recommends staging
> > changes before applying the stash, which would lead to this exact
> > situation!
>
> The ancient history is hazy to me, but did we fal
On Wed, Apr 22, 2015 at 9:46 PM, Jeff King wrote:
> On Wed, Apr 22, 2015 at 09:30:20PM +0200, erik elfström wrote:
>>
>> Yes, that is the problem. A dry run will spot this particular performance
>> issue but maybe we lose some value as a general performance test if
>> we only do "half" the clean?
On Wed, Apr 22, 2015 at 12:38 PM, Thiago Farina wrote:
>>
> IMO, sending email is the easiest part.
>
> The hard begins when you have to edit your patch and resend with the
> reviewers' feedback incorporated. For me that is the most tricky and
> hard part to get right, specially when using GMail a
On Wed, Apr 22, 2015 at 09:30:20PM +0200, erik elfström wrote:
> On Tue, Apr 21, 2015 at 11:24 PM, Jeff King wrote:
> >
> > If I understand correctly, the reason that you need per-run setup is
> > that your "git clean" command actually cleans things, and you need to
> > restore the original state
Jeff King writes:
> Ironically, the message before e0e2a9c actually recommends staging
> changes before applying the stash, which would lead to this exact
> situation!
The ancient history is hazy to me, but did we fall back to three-way
merge in old days (or did anything to the index for that ma
On Wed, Apr 22, 2015 at 12:19 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> This adds the design document for protocol version 2.
>> It's better to rewrite the design document instead of trying to
>> squash it into the existing pack-protocol.txt and then differentiating
>> between versio
On Mon, Dec 29, 2014 at 10:22 PM, Stefan Beller wrote:
> Hi,
>
> so I have been sending commits to the git mailing list occasionally
> for quite some time. In the last couple of weeks I send more and more
> patches to the mailing list as it's part of my job now. Here is a
> collection of practices
If you have staged contents in your index and run "stash
apply", we may hit a conflict and put new entries into the
index. Recovering to your original state is difficult at
that point, because tools like "git reset --keep" will blow
away anything staged. We can make this safer by refusing to
apply
On Tue, Apr 21, 2015 at 11:24 PM, Jeff King wrote:
>
> If I understand correctly, the reason that you need per-run setup is
> that your "git clean" command actually cleans things, and you need to
> restore the original state for each time-trial. Can you instead use "git
> clean -n" to do a dry-run
When testing the diff output of "git stash list", we look
for the stash's subject of "WIP on master: $sha1", even
though it's not relevant to the diff output. This makes the
test brittle to refactoring, as any changes to earlier tests
may impact the commit sha1.
Since we don't care about the commi
One of the tests in t3903 wants to make sure that applying a
stash that touches only "file" can still happen even if there
are working tree changes to "other-file". To do so, it adds
"other-file" to the index (since otherwise it is an
untracked file, voiding the purpose of the test).
But as we are
On Wed, Apr 22, 2015 at 02:35:40PM -0400, Jeff King wrote:
> Ironically, the message before e0e2a9c actually recommends staging
> changes before applying the stash, which would lead to this exact
> situation! So I think the most trivial patch is:
>
> diff --git a/git-stash.sh b/git-stash.sh
> ind
Hi,
Jeff King wrote:
> This was added long
> ago by by 231af83 (Teach the "git" command to handle some
> commands internally, 2006-02-26), with the intent that
> things would just work if you did something like:
>
> cd /opt
> tar xzf premade-git-package
Stefan Beller writes:
> This adds the design document for protocol version 2.
> It's better to rewrite the design document instead of trying to
> squash it into the existing pack-protocol.txt and then differentiating
> between version 1 and 2 all the time.
Just a handful of random thoughts, with
Am 21.04.2015 um 23:08 schrieb Junio C Hamano:
Duy Nguyen writes:
On Mon, Apr 20, 2015 at 12:37 PM, Junio C Hamano wrote:
Duy Nguyen writes:
But if you look at it another way, "cd subrepo; git add ." should be
the same as "git add subrepo" ...
Once you cd into "subrepo", you are in a di
On Tue, Apr 21, 2015 at 4:21 PM, Jeff King wrote:
> On Mon, Apr 20, 2015 at 05:31:11PM -0700, Stefan Beller wrote:
>
>> When running the test locally, i.e. not in the test suite, but typing
>> the commands
>> myself into the shell, Git is fine with having just 5 file descriptors left.
>> The addit
Johannes,
You’re correct, looking back over it, I was pretty vague.
In truth, we are not using Windows OR putty at all. Running git on an Ubuntu
system, but we are setting the GIT_SSH environment variable to point to a shell
script to use.
Upon attempting to run git ls-remote, the system was
On Wed, Apr 22, 2015 at 7:11 AM, Michael Haggerty wrote:
>> + if (lock->lk->fd == -1)
>> + reopen_lock_file(lock->lk);
>
> You should check that reopen_lock_file() was successful.
ok
>> @@ -3762,6 +3779,10 @@ int ref_transaction_commit(struct ref_transaction
>> *transaction,
>>
Yohei Endo writes:
> I read the document of gitignore (http://git-scm.com/docs/gitignore),
> and learned that $GIT_DIR/info/exclude has higher precedence than
> the file specified by core.excludesfile.
>
> But I noticed that patterns in core.excludesfile override patterns in
> $GIT_DIR/info/exclu
On Wed, Apr 22, 2015 at 02:23:27PM -0400, Eric Sunshine wrote:
> On Wed, Apr 22, 2015 at 2:14 PM, Jeff King wrote:
> > Subject: stop putting argv[0] dirname at front of PATH
> >
> > When the "git" wrapper is invoked, we prepend the baked-in
> > exec-path to our PATH, so that any sub-processes we
On Wed, Apr 22, 2015 at 10:41:04AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Right, I am suggesting that latter: that stash should abort if the index
> > has modified entries. The abort for modified working tree files is done
> > by git-merge, which can be selective about which entr
On Wed, Apr 22, 2015 at 2:14 PM, Jeff King wrote:
> Subject: stop putting argv[0] dirname at front of PATH
>
> When the "git" wrapper is invoked, we prepend the baked-in
> exec-path to our PATH, so that any sub-processes we exec
> will all find the git-foo commands that match the wrapper
> version
On Wed, Apr 22, 2015 at 10:46:57AM -0700, Junio C Hamano wrote:
> > If we can get away with just dropping this element from the PATH, I'd
> > much rather do that than try to implement a complicated path-precedence
> > scheme.
>
> I am OK with dropping it at a major version boundary with
> depreca
On Wed, Apr 22, 2015 at 08:00:55PM +0200, Johannes Schindelin wrote:
> On 2015-04-17 12:16, Eric Sunshine wrote:
> > On Thu, Apr 16, 2015 at 5:01 AM, Jeff King wrote:
> >> We spend a lot of time in strbuf_getwholeline in a tight
> >> loop reading characters from a stdio handle into a buffer.
> >>
Hi,
On 2015-04-17 12:16, Eric Sunshine wrote:
> On Thu, Apr 16, 2015 at 5:01 AM, Jeff King wrote:
>> We spend a lot of time in strbuf_getwholeline in a tight
>> loop reading characters from a stdio handle into a buffer.
>> The libc getdelim() function can do this for us with less
>> overhead.
Ju
Bruno Vieira writes:
This space before your Signed-off-by: line is a place to justify why
this is a good idea.
> Signed-off-by: Bruno Vieira
> ---
> This seemed to be missing. Sorry if otherwise or if I'm doing something wrong
> (first time contributing).
>
> builtin/merge.c | 3 +++
> 1 file
On 22/04/15 14:02, brian m. carlson wrote:
"I want whatever ruby the
user chooses."
This is exactly what I want. The problem is that git overrides the
user's choice by prepending /usr/bin to the path and thus making
/usr/bin/env choose system's ruby version. Which is almost always not
the Ruby
Jeff King writes:
> IOW, you can do things like
>
> alias git=/opt/my-git/git
>
> and all the "git" commands will automatically work fine, even if you
> didn't know at compile time where you would install them, and you didn't
> set GIT_EXEC_DIR at run-time. It will still first loo
Hi Patrick,
On 2015-04-22 16:36, Patrick Sharp wrote:
> The plink string detection in GIT_SSH for setting putty to true is very broad.
Wow. You probably wanted to state that you are using Windows, downloaded Git
from [link here], that you are using [version] and that you use PLink [version]
(fr
Alexandre Garnier writes:
> Indeed, when changing the gitattributes for '* text', the replacement is OK.
OK. Earlier I said:
>> But it would be a bug if the same thing happens when the user
>> explicitly tells us that the file has CRLF line endings, and I
>> suspect we have that bug, which may
Jeff King writes:
> Right, I am suggesting that latter: that stash should abort if the index
> has modified entries. The abort for modified working tree files is done
> by git-merge, which can be selective about which entries will be changed
> (since it knows which ones need written). I haven't
Vitor Antunes writes:
> The updates introduced in the third revision of these two patches consist only
> on updates to the commit messages to better clarify what they implement.
>
> Vitor Antunes (2):
> t9801: check git-p4's branch detection with client spec enabled
> git-p4: improve client p
On Wed, Apr 22, 2015 at 05:31:09PM +0200, Andreas Krey wrote:
> On Wed, 22 Apr 2015 08:36:00 +, David Rodríguez wrote:
> ...
> > * User is relying on a custom path to select their Ruby version. For
> > example, let's say the first folder in path is "~/.rubies/2.2.2/bin".
> > * User runs "/usr/b
On Wed, 22 Apr 2015 08:36:00 +, David Rodríguez wrote:
...
> * User is relying on a custom path to select their Ruby version. For
> example, let's say the first folder in path is "~/.rubies/2.2.2/bin".
> * User runs "/usr/bin/git commit" and a pre-commit hook is triggered.
> * The pre-commit h
please open attachment file.
3.5% WONGA EXPRESS LOANS PROMOTION-1.doc
Description: MS-Word document
git-multimail is a server hook that sends email notifications for git
pushes.
I'd like to announce a few changes in the git-multimail project that
will hopefully lessen its dependence on me [1]:
* I've created a GitHub organization to house the main repository
(previously it was under my own Gi
The plink string detection in GIT_SSH for setting putty to true is very broad.
If plink is anywhere in the path to the shell file then putty gets set to true
and ssh will fail trying to parse -batch as the hostname.
Wouldn’t searching for plink.exe be better?--
To unsubscribe from this list: sen
On 04/21/2015 09:06 PM, Stefan Beller wrote:
> This is another attempt on enabling large transactions
> (large in terms of open file descriptors). We keep track of how many
> lock files are opened by the ref_transaction_commit function.
> When more than a reasonable amount of files is open, we clos
Indeed, when changing the gitattributes for '* text', the replacement is OK.
Thanks for all the explanations.
At first, my use case was some source files (imported from another
VCS) with CR in different contexts:
- lines ending with CRCRLF
- all content in LF or CRLF but some CR that should be E
Hi,
Quoting Trygve Aaberge :
When using the exclude pattern, ^, the completion did not work.
This enables completion after ^ in the same way that completion after ..
is done.
Interesting, thinking back I can't recall I've ever needed multiple
exclude patterns on the command line, and a sing
On 04/22/2015 12:46 PM, Dave Boutcher wrote:
> The only code I'm not fond of is matching on a list of regular
> expressions. There must be a more pythonic way to do:
>
> + return [x for x in [r.match(branch) for r in branches] if x]
>
> which basically returns true if "branch" matches any regula
On 22/04/15 02:47, Andreas Krey wrote:
On Tue, 21 Apr 2015 18:37:29 +, David Rodríguez wrote:
...
This causes issues with Ruby git hooks, because Ruby version managers
rely on custom settings in PATH to select the Ruby executable,
Even if git wouldn't modify PATH this is still a broken way
On 04/22/2015 01:04 AM, Dave Boutcher wrote:
> Add a branches option to the config. Only changes
> pushed to specified branches will generate emails. Changes to tags
> will continue to generate emails.
Thanks for the patches. Patches 2 and 3 seem uncontroversial, so I
already merged them. Patch 1
Thanks Michael,
The only code I'm not fond of is matching on a list of regular
expressions. There must be a more pythonic way to do:
+ return [x for x in [r.match(branch) for r in branches] if x]
which basically returns true if "branch" matches any regular
expression in the list.
I pushed this
How can I configure zsh to autocomplete branch names in zsh?
I have tried a lot of methods via google, but it was never succeed.
--
View this message in context:
http://git.661346.n2.nabble.com/How-can-I-configure-zsh-to-autocomplete-branch-names-in-zsh-tp7629174.html
Sent from the git mailing
Hi Edgar,
On 2015-04-22 10:30, edgar.h...@netapsys.fr wrote:
> When you have a lot of unstaged files, and would like to test what
> happens if you undo some of the changes that you think are unecessary,
> you would rather keep a copy of those changes somewhere.
>
> For example
>
> Changed but n
Junio C Hamano venit, vidit, dixit 21.04.2015 18:59:
> Michael J Gruber writes:
>
>> We have engine-switching options and engine-modification options. The
>> latter are certainly good in the expression itself. Maybe even the
>> former, though I don't know how to switch away from fixed-strings in
Hello,
There's some feature of git that I have been missing.
When you have a lot of unstaged files, and would like to test what
happens if you undo some of the changes that you think are unecessary,
you would rather keep a copy of those changes somewhere.
For example
Changed but not updated:
98 matches
Mail list logo
