Signed-off-by: Matthieu Moy
---
Ram's patch lacks a test. Here it is. Fails without Ram's patch, and
passes with it.
Can be squashed into Ram's patch.
t/t3420-rebase-autostash.sh | 17 +
1 file changed, 17 insertions(+)
diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-
On Mon, May 19, 2014 at 10:35:56PM +0300, Michael S. Tsirkin wrote:
> I tried to fump the whole history of qemu with format-patch.
> It crashes both with v2.0.0-rc2-21-g6087111
> and with git 1.8.3.1:
>
> ~/opt/libexec/git-core/git-format-patch --follow -o patches/all
> e63c3dc74bfb90e4522d075d0d
On Tue, May 20, 2014 at 01:49:31AM +, brian m. carlson wrote:
> On Mon, May 19, 2014 at 07:28:17PM +0400, Alexey Shumkin wrote:
> > The tested encoding is always available in a variable. Use it instead of
> > hardcoding. Also, to be in line with other tests use ISO8859-1
> > (uppercase) rather
On Mon, May 19, 2014 at 10:46:21PM -0700, Jeremiah Mahler wrote:
> > Avoiding that is easy with an indirection, no? Something like this
> > at the top:
> >
> > static const char *the_default_signature = git_version_string;
> > static const char *signature = the_default_signature;
> >
> > an
On Mon, May 19, 2014 at 09:54:33AM -0700, Junio C Hamano wrote:
> Jeremiah Mahler writes:
>
> > On Sat, May 17, 2014 at 06:00:14AM -0400, Jeff King wrote:
> >>
>
> Avoiding that is easy with an indirection, no? Something like this
> at the top:
>
> static const char *the_default_signature =
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> > Felipe Contreras writes:
>> >
>> >> We could. Personally I don't see the point of making the warning any
>> >> more annoying
>>
>> If we were giving the users a choice of "no thanks, I'll keep using
>> the
Richard Hansen writes:
> On 2014-05-19 19:46, Junio C Hamano wrote:
>> "Jason St. John" writes:
>>> @@ -53,7 +53,7 @@ Updates since v1.9 series
>>> UI, Workflows & Features
>>>
>>> * The "multi-mail" post-receive hook (in contrib/) has been updated
>>> - to a more recent version from the
On 2014-05-19 19:46, Junio C Hamano wrote:
> "Jason St. John" writes:
>> @@ -53,7 +53,7 @@ Updates since v1.9 series
>> UI, Workflows & Features
>>
>> * The "multi-mail" post-receive hook (in contrib/) has been updated
>> - to a more recent version from the upstream.
>> + to a more recent
Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Felipe Contreras writes:
> >
> >> We could. Personally I don't see the point of making the warning any
> >> more annoying
>
> If we were giving the users a choice of "no thanks, I'll keep using
> the obsolete one", then trying to be a low
On Mon, May 19, 2014 at 07:28:17PM +0400, Alexey Shumkin wrote:
> The tested encoding is always available in a variable. Use it instead of
> hardcoding. Also, to be in line with other tests use ISO8859-1
> (uppercase) rather then iso8895-1.
You wrote "iso8895" when I think you meant "iso8859".
--
"Jason St. John" writes:
> Signed-off-by: Jason St. John
> ---
Please accept "Thanks" for all the hunks I won't comment below; they
looked correct to me.
> @@ -53,7 +53,7 @@ Updates since v1.9 series
> UI, Workflows & Features
>
> * The "multi-mail" post-receive hook (in contrib/) has bee
On Mon, 19 May 2014, Junio C Hamano wrote:
> If Ubuntu does not want to use highlight, it can apply a change like the
> patch in question as part of their fork to make the end result
> consistent and they are failing to do so.
Sure, Ubuntu can apply that patch, but the larger problem remains: if
On Fri, May 16, 2014 at 2:20 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> Add a flag that allows us to truncate the reflog before we write the update.
>>
>> Signed-off-by: Ronnie Sahlberg
>> ---
>
> Until we read the callers it is hard to see how such a feature is
> useful, though.
Ronnie Sahlberg writes:
> I am not sure if we need transactions for other types of data, such as
> sha1 objects, but if it turns out we do in the future we can rename
> these functions again.
I was wrong (and I think you read it in the later patch review).
If we need transaction for other types
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> We could. Personally I don't see the point of making the warning any
>> more annoying
If we were giving the users a choice of "no thanks, I'll keep using
the obsolete one", then trying to be a low key and giving them a way
to squelch wi
On Fri, May 16, 2014 at 2:15 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> Rename the transaction functions. Remove the leading ref_ from the names
>> and append _sha1 to the names for functions that create/delete/update sha1
>> refs.
>> ...
>> - transaction = ref_transacti
On Fri, May 16, 2014 at 2:35 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> Allow to make multiple reflog updates to the same ref during a transaction.
>> This means we only need to lock the reflog once, during the first update that
>> touches the reflog, and that all further updates ca
On Fri, May 16, 2014 at 3:01 PM, Eric Sunshine wrote:
> On Fri, May 16, 2014 at 5:35 PM, Junio C Hamano wrote:
>> Ronnie Sahlberg writes:
>>
>>> Allow to make multiple reflog updates to the same ref during a transaction.
>>> This means we only need to lock the reflog once, during the first updat
Not all shells subject the prompt string to parameter expansion. Test
whether the shell will expand the value of PS1, and use the result to
control whether raw ref names are included directly in PS1.
This fixes a regression introduced in commit 8976500 ("git-prompt.sh:
don't put unsanitized branc
On Fri, May 16, 2014 at 2:24 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> When performing a reflog transaction update, only write to the reflog iff
>> msg is non-NULL. This can then be combined with REFLOG_TRUNCATE to perform
>> an update that only truncates but does not write.
>>
>>
On Mon, May 19, 2014 at 02:34:26PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > test ack! handling
> >
> > Signed-off-by: Michael S. Tsirkin
>
> Will queue with this squashed in.
Thanks! And sorry about the style issues.
> 4/4 seems to have some style issues as well, but
Felipe Contreras writes:
>> We could add these two to the warning, then, to discourage people
>> who see "please visit this URL" and say "Yuck, I have no time for
>> that" without actually visiting.
>
> We could. Personally I don't see the point of making the warning any
> more annoying. The inst
When a user invokes
$ git rebase -i @~3
with dirty files and rebase.autostash turned on, and exits the $EDITOR
with an empty buffer, the autostash fails to apply. Although the primary
focus of rr/rebase-autostash was to get the git-rebase--backend.sh
scripts to return control to git-rebase.sh,
Ævar Arnfjörð Bjarmason wrote:
> On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras
> wrote:
> > This tool finds people that might be interested in a patch, by going
> > back through the history for each single hunk modified, and finding
> > people that reviewed, acknowledged, signed, or authored t
"Michael S. Tsirkin" writes:
> test ack! handling
>
> Signed-off-by: Michael S. Tsirkin
Will queue with this squashed in.
4/4 seems to have some style issues as well, but I didn't look very
closely.
Thanks.
t/t3415-rebase-autosquash.sh | 12 ++--
1 file changed, 6 insertions(+), 6 d
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >
> >> - The "always warn" does not force update at the point of use, but
> >>it still does not help them to notice well before they try to use
> >>it for the first time after update;
> >
> > I don't understan
Felipe Contreras writes:
> Junio C Hamano wrote:
>>
>> After looking at the reverse-depends list of packages, my faith is
>> strengthened in that the Git ecosystem is truly maturing and useful
>> third-party plug-ins will be picked up by distro packagers.
>
> Where is git-imerge packaged?
I did
On Mon, May 19, 2014 at 11:15 PM, Thomas Braun
wrote:
> Am 19.05.2014 21:33, schrieb Jonathan Nieder:
>
>> Hi,
>>
>> Thomas Braun wrote:
>>
>>> pushing over the dump git protocol with a windows git client.
>>
>>
>> I've never heard of the dump git protocol. Do you mean the git
>> protocol that's
Am 19.05.2014 21:33, schrieb Jonathan Nieder:
Hi,
Thomas Braun wrote:
pushing over the dump git protocol with a windows git client.
I've never heard of the dump git protocol. Do you mean the git
protocol that's used with git:// URLs?
You are right I mean the protocol involving git:// URLs
Felipe Contreras writes:
> ...
> Which will generate the integration instructions for you:
>
> % git reintegrate --cat
> base master
> merge jl/submodule-mv
>
> Moving a regular file in a repository with a .gitmodules file was
> producing a warning 'Could not find section in .gitmod
Christian Couder writes:
> This patch series comes from what Peff sent in the following thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/243361/focus=243528
>
> The only changes compared to v2 are in the test (8/10) and documentation
> patches (10/10). Thanks to Peff.
>
> Christ
On Mon, May 19, 2014 at 10:00 PM, Erik Faye-Lund wrote:
> On Mon, May 19, 2014 at 9:33 PM, Jonathan Nieder wrote:
>> Hi,
>>
>> Thomas Braun wrote:
>>
>>> pushing over the dump git protocol with a windows git client.
>>
>> I've never heard of the dump git protocol. Do you mean the git
>> protocol
On Mon, May 19, 2014 at 9:33 PM, Jonathan Nieder wrote:
> Hi,
>
> Thomas Braun wrote:
>
>> pushing over the dump git protocol with a windows git client.
>
> I've never heard of the dump git protocol. Do you mean the git
> protocol that's used with git:// URLs?
>
> [...]
>> Alternative approaches
I tried to fump the whole history of qemu with format-patch.
It crashes both with v2.0.0-rc2-21-g6087111
and with git 1.8.3.1:
~/opt/libexec/git-core/git-format-patch --follow -o patches/all
e63c3dc74bfb90e4522d075d0d5a7600c5145745..
Backtrace:
Program received signal SIGSEGV, Segmentation faul
Hi,
Thomas Braun wrote:
> pushing over the dump git protocol with a windows git client.
I've never heard of the dump git protocol. Do you mean the git
protocol that's used with git:// URLs?
[...]
> Alternative approaches considered but deemed too invasive:
> - Rewrite read/write wrappers in mi
Since commit 0c499ea60f the send-pack builtin uses the side-band-64k
capability if advertised by the server. Unfortunately this breaks
pushing over the dump git protocol with a windows git client.
The detailed reasons for this breakage are (by courtesy of Jeff
Preshing, quoted from
https://groups.
On Mon, May 19, 2014 at 9:17 PM, Thomas Braun
wrote:
> Am Montag, den 19.05.2014, 11:59 +0200 schrieb Erik Faye-Lund:
>> On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund wrote:
>> > On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt
>> > wrote:
>> >> Am 5/6/2014 2:17, schrieb Eric Wong:
>> >>> Users
Am Montag, den 19.05.2014, 11:59 +0200 schrieb Erik Faye-Lund:
> On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund wrote:
> > On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt wrote:
> >> Am 5/6/2014 2:17, schrieb Eric Wong:
> >>> Users may already store sensitive data such as imap.pass in
> >>> ..git
On Sat, May 17, 2014 at 8:35 AM, Michael Haggerty wrote:
> On 05/16/2014 07:37 PM, Ronnie Sahlberg wrote:
>> Wrap all the ref updates inside a transaction to make the update atomic.
>>
>> Signed-off-by: Ronnie Sahlberg
>> ---
>> builtin/receive-pack.c | 20 ++--
>> 1 file changed
Felipe Contreras writes:
> Junio C Hamano wrote:
>
>> 2. add warning that is given every time the scripts are run and
>> give the same instruction as in README.
>>
>> 3. (optional) cripple the script to make them always fail after
>> showing the same warning as above.
>
> This is w
Jeff King writes:
> On Mon, May 19, 2014 at 10:25:10AM -0700, Junio C Hamano wrote:
>
>> The headers up to committer are cast in stone in their ordering, and
>> I do not immediately see how loosening it would be beneficial.
>>
>> Unless you are trying to give users a new way to record exactly th
I have moved the patch to add an err argument to this branch and
update all patches that adds
calls to ref_Transaction_begin to the new signature.
Please see
https://github.com/rsahlberg/git/tree/ref-transactions
Thanks!
On Sat, May 17, 2014 at 6:14 AM, Michael Haggerty wrote:
> On 05/16/2014
I have moved the patch to add &err to ref_transaction_begin to the
current patch series.
Please see
https://github.com/rsahlberg/git/tree/ref-transactions
On Mon, May 19, 2014 at 10:16 AM, Ronnie Sahlberg wrote:
> On Sat, May 17, 2014 at 6:09 AM, Michael Haggerty
> wrote:
>> On 05/16/2014 07:3
On Mon, May 19, 2014 at 10:25:10AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It might make sense to just teach parse_commit_header to be a little
> > more thorough; it has to read past those lines anyway to find the author
> > and committer lines, so it would not be much more expens
Jeff King writes:
> It might make sense to just teach parse_commit_header to be a little
> more thorough; it has to read past those lines anyway to find the author
> and committer lines, so it would not be much more expensive to note
> them. And then of course the code needs to be pulled out of
On Sat, May 17, 2014 at 6:33 AM, Michael Haggerty wrote:
> On 05/16/2014 07:37 PM, Ronnie Sahlberg wrote:
>> Change create_branch to use a ref transaction when creating the new branch.
>> ref_transaction_create will check that the ref does not already exist and
>> fail
>> otherwise meaning that w
Jens Lehmann writes:
> Am 17.05.2014 14:23, schrieb Pat Thoyts:
>>
>> The analysis about the major version number being significant is
>> correct. ...
>>
>> package vsatisfies $::_git_version 1.7.0-
>>
>> will suffice.
>
> Junio, please replace my old version with this.
Thanks, both. Will r
On Sat, May 17, 2014 at 6:09 AM, Michael Haggerty wrote:
> On 05/16/2014 07:37 PM, Ronnie Sahlberg wrote:
>> Change tag.c to use ref transactions for all ref updates.
>>
>> Signed-off-by: Ronnie Sahlberg
>> ---
>> builtin/tag.c | 14 --
>> 1 file changed, 8 insertions(+), 6 deletions
On Monday, May 19, 2014 12:01:07 PM you wrote:
> On Mon, May 19, 2014 at 09:12:47PM +0630, Arup Rakshit wrote:
> > Is there any difference between the below 2 commands ? I didn't see
> > anything.
> >
>
> Does that help?
For me who is in Git just 6-7 days, It is huge. On your way, I was walking
Anders Kaseorg writes:
> Yes; when I noticed this failure, I asked Jonathan to add source-highlight
> as a build dependency in Debian (https://bugs.debian.org/745591). But
> then Ubuntu forked the packaging to revert this change
> (https://bugs.launchpad.net/bugs/1316810), because source-high
On Fri, May 16, 2014 at 3:54 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> --- a/builtin/fetch.c
>> +++ b/builtin/fetch.c
> [...]
>> @@ -384,15 +384,16 @@ static int s_update_ref(const char *action,
>> snprintf(msg, sizeof(msg), "%s: %s", rla, action);
>>
>> errno = 0;
>> -
On Fri, May 16, 2014 at 3:52 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> Change store_updated_refs to use a single ref transaction for all refs that
>> are updated during the fetch. This makes the fetch more atomic when update
>> failures occur.
>
> Fun.
>
> [...]
>> --- a/builtin/fet
Jeremiah Mahler writes:
> On Sat, May 17, 2014 at 06:00:14AM -0400, Jeff King wrote:
>>
>> If you wanted to know whether it was set, I guess you'd have to compare
>> it to the default, like:
>>
>> if (signature_file) {
>> if (signature && signature != git_version_string)
>>
On Mon, May 19, 2014 at 09:27:47PM +0630, Arup Rakshit wrote:
> > Is there any difference between the below 2 commands ? I didn't see
> > anything.
> >
> > git rm --cached -- ..
> > git checkout -- ..
>
> Please Ignore the previous.
Too late. :)
> I apologize to rewriting and increase th
On Mon, May 19, 2014 at 11:49:09AM -0400, Jeff King wrote:
> On Mon, May 19, 2014 at 07:03:58PM +0400, Marat Radchenko wrote:
>
> > `git push` writes to stderr instead of stdout
>
> That's by design.
>
> Which one is correct is largely a matter of philosophy / mental model.
> This case has been
"Michael S. Tsirkin" writes:
> Well RHEL6 apparently comes with git 1.7.1, there are
> probably others.
>
> The problem isn't theorectical actually,
Thanks. Let's do the fix for 2.0 then.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vge
On Monday, May 19, 2014 09:12:47 PM you wrote:
> Hi,
>
> Is there any difference between the below 2 commands ? I didn't see
> anything.
>
> git rm --cached -- ..
> git checkout -- ..
Please Ignore the previous.
I apologize to rewriting and increase the load of this mailing list. I
actua
On Mon, May 19, 2014 at 09:12:47PM +0630, Arup Rakshit wrote:
> Is there any difference between the below 2 commands ? I didn't see anything.
>
> git rm --cached -- ..
This one removes the index entries for those files.
> git checkout -- ..
This one checks out the content from the index
On 5/19/2014 2:44 AM, Erik Faye-Lund wrote:
On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt
wrote:
I'm not proficient enough to add any ACL fiddling to fchmod that
would be required by the above change, whose purpose is to be
strict about permissions. Nor am I interested (who the heck is
sharing
On Mon, May 19, 2014 at 07:03:58PM +0400, Marat Radchenko wrote:
> `git push` writes to stderr instead of stdout
That's by design.
Which one is correct is largely a matter of philosophy / mental model.
This case has been discussed before:
http://thread.gmane.org/gmane.comp.version-control.git
Hi,
Is there any difference between the below 2 commands ? I didn't see anything.
git rm --cached -- ..
git checkout -- ..
--
===
Regards,
Arup Rakshit
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
Use `tformat` to avoid using of `echo` to complete end of line.
Signed-off-by: Alexey Shumkin
---
t/t4205-log-pretty-formats.sh | 52 +++
1 file changed, 13 insertions(+), 39 deletions(-)
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-for
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given
length with an appropriate padding. This works for non-ASCII texts when
i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
message encoding) but does not work when i18n.logOutputEncoding is NOT
UTF-8.
In 7e77
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given
length with an appropriate padding. This works for non-ASCII texts when
i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
message encoding) but does not work when i18n.logOutputEncoding is NOT
UTF-8.
There w
The tested encoding is always available in a variable. Use it instead of
hardcoding. Also, to be in line with other tests use ISO8859-1
(uppercase) rather then iso8895-1.
Signed-off-by: Alexey Shumkin
---
t/t4041-diff-submodule-option.sh | 7 +--
t/t4205-log-pretty-formats.sh| 11 ++
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
That was introduced in a742f2a (t4205 (log-pretty-formats): don't
hardcode SHA-1 in expected outputs, 2013-06-26) but unfortunately was
not followed in 5e1361c (log: properly handle decorations with chain
This patch series differs from the previous (v2) version in the following:
t4205 refactored: hardcoded SHA-1 digests replaced with variabled
Tested encoding `iso8859-1` replaced with variable (and uppercased to be in line
in other tests)
Usage of `format` + `echo` replaced with `tformat`
brian m
On Mon, May 19, 2014 at 06:12:10PM +1000, Bryan Turner wrote:
> For starters, to return an error message, your status must be 200 OK.
> You can't return any other status code or Git will interpret your
> error as some form of _HTTP_ error rather than a _git_ error.
As of git v1.8.3, git will show
`git push` writes to stderr instead of stdout
Steps to reproduce:
mkdir foo
cd foo
git init
echo foo > fo
git add -A
git commit -am "foo"
git push . HEAD:refs/heads/newbranch 2>out
Expected: `out` file is empty
Actual: `out` file contents:
To .
* [new branch] HEAD -> newbra
On Mon, May 19, 2014 at 08:17:07AM -0500, Robert Dailey wrote:
> I have run the following command:
>
> log --graph --abbrev-commit --decorate --date=relative
> --format=format:'%C(bold blue)%h%C(reset)%x09%C(bold
> green)(%ar)%C(reset)%C(bold yellow)%d%C(reset) %C(dim
> white)%an%C(reset) - %C(wh
On Mon, May 19, 2014 at 03:05:42PM +0200, Alexandre Badez wrote:
> The '.' directory is not the same as the root directory; you can see
> that the /README.md and /./README.md are different.
Right. Inside git trees, "." as an entry name does not have any special
meaning. However, because it does h
From: Cezary Zawadka
Date: Tue, 13 Jul 2010 16:17:43 +0200
[efl: moved MinGW-specific part to compat/]
[jes: fixed compilation on non-Windows]
Eric Sunshine fixed mingw_offset_1st_component() to return consistently "foo"
for UNC "//machine/share/foo", cf
http://groups.google.com/group/msysgit/br
I have run the following command:
log --graph --abbrev-commit --decorate --date=relative
--format=format:'%C(bold blue)%h%C(reset)%x09%C(bold
green)(%ar)%C(reset)%C(bold yellow)%d%C(reset) %C(dim
white)%an%C(reset) - %C(white)%s%C(reset)'
After running this, I am seeing tag labels in the log grap
Hi,
Today I've issue a problem with git.
I've start a little project on github ( https://github.com/Djabx/mgd ).
And I used https://stackedit.io/ for editing my README.md file.
When I publish it on my repo (stackedit), I've set the destination
file path to "./README.md".
The problem is, that Gi
On Sun, May 18, 2014 at 08:29:38PM +0200, Christian Couder wrote:
> +static int create_graft(int argc, const char **argv, int force)
> +{
> + unsigned char old[20], new[20];
> + const char *old_ref = argv[0];
> + struct strbuf buf = STRBUF_INIT;
> + struct strbuf new_parents = STRB
On Mon, May 19, 2014 at 11:42:07AM +0200, Michael Haggerty wrote:
> On 05/18/2014 08:29 PM, Christian Couder wrote:
> > The usage string for this option is:
> >
> > git replace [-f] --graft [...]
> >
> > First we create a new commit that is the same as
> > except that its parents are [...]
> >
On Sun, May 18, 2014 at 01:22:02PM -0700, Jeremiah Mahler wrote:
> @@ -742,6 +743,8 @@ static int git_format_config(const char *var, const char
> *value, void *cb)
> }
> if (!strcmp(var, "format.signature"))
> return git_config_string(&signature, var, value);
> + if
On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras
wrote:
> This tool finds people that might be interested in a patch, by going
> back through the history for each single hunk modified, and finding
> people that reviewed, acknowledged, signed, or authored the code the
> patch is modifying.
>
> It
On Fri, May 16, 2014 at 2:42 AM, David Turner wrote:
>> I assume you won't change your mind about this. Which is fine to me. I
>> will still try out my approach with your libwatchman though. Just
>> curious about its performance and complexity, compared to your
>> approach.
>
> I am open-minded he
On Sat, May 17, 2014 at 11:31 PM, Pasha Bolokhov
wrote:
> Now if you guys don't see anything against this, I would shoot out a
> patch?
>
If you have written the patch already, I see no harm in sending it
here. I'm concerned about the perfomance impact on this code, which is
already slow whe
On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund wrote:
> On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt wrote:
>> Am 5/6/2014 2:17, schrieb Eric Wong:
>>> Users may already store sensitive data such as imap.pass in
>>> ..git/config; making the file world-readable when "git config"
>>> is called t
On 05/18/2014 08:29 PM, Christian Couder wrote:
> The usage string for this option is:
>
> git replace [-f] --graft [...]
>
> First we create a new commit that is the same as
> except that its parents are [...]
>
> Then we create a replace ref that replace with
> the commit we just created.
>
On Mon, 2014-05-19 at 18:12 +1000, Bryan Turner wrote:
> On Sat, May 17, 2014 at 9:01 AM, brian m. carlson
> wrote:
> > On Tue, May 13, 2014 at 09:39:59AM +0200, "Ákos, Tajti" wrote:
> >> Dear List,
> >>
> >> we implemented our own git smart http server to be able to check
> >> permissions
> >> a
[ Cc-ing Ramkumar ]
Karen Etheridge writes:
> scenario:
> - edit some tracked files; do not add them to the index
> - "git config rebase.autostash true"
> - "git rebase -i HEAD~3" (an autostash will be created)
> - delete the entire buffer and save/exit the editor - this will abort the
> reba
Hi all!
The Git Bash completion script does not complete the `--abort` option
for the `merge ` command.
It correctly completes the other flags.
It correctly completes the `--abort` flag for `rebase` and others.
`git merge --abort` is considered another form of the merge command
instead of a simp
On Sat, May 17, 2014 at 9:01 AM, brian m. carlson
wrote:
> On Tue, May 13, 2014 at 09:39:59AM +0200, "Ákos, Tajti" wrote:
>> Dear List,
>>
>> we implemented our own git smart http server to be able to check permissions
>> and other thing before pushes. It works fine, however, the error messages we
On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt wrote:
> Am 5/6/2014 2:17, schrieb Eric Wong:
>> Users may already store sensitive data such as imap.pass in
>> ..git/config; making the file world-readable when "git config"
>> is called to edit means their password would be compromised
>> on a share
> scenario:
> - edit some tracked files; do not add them to the index
> - "git config rebase.autostash true"
> - "git rebase -i HEAD~3" (an autostash will be created)
> - delete the entire buffer and save/exit the editor - this will abort the
> rebase
>
> poof, the autostash is gone (it is not re
Am 5/6/2014 2:17, schrieb Eric Wong:
> Users may already store sensitive data such as imap.pass in
> ..git/config; making the file world-readable when "git config"
> is called to edit means their password would be compromised
> on a shared system.
>
> [v2: updated for section renames, as noted by
89 matches
Mail list logo
