Ramkumar Ramachandra wrote:
> diff --git a/transport-helper.c b/transport-helper.c
> index 06c08a1..db9bd18 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
Oh, and we have to remove test 23 - "proper failure checks for
pushing" from t5801-remote-helpers.sh.
--
To unsubscribe from this
Jeff King wrote:
> So I'm not sure if there is a better option than reverting 81d340d4 and
> living with the lesser of two evils (no good message when the helper
> dies silently).
I dug around, but I still can't justify that there is no better
option. Could you write a commit message for this?
-
On Fri, Jun 21, 2013 at 12:07:50PM +0530, Ramkumar Ramachandra wrote:
> Yesterday's jc publish fixed it: 6c473a5 (build: generate and clean
> test scripts, 2013-06-07) graduated to master; it adds $NO_INSTALL to
> the target "all", among other things.
Ah, makes sense. Sorry to be slow.
-Peff
--
Jeff King wrote:
> So I do not see any problem with the current Makefile. Running "make" or
> "make test" should let t5800 pass. Can you describe how you are
> triggering the issue in more detail?
master, at the time of reporting the issue:
artagnon|master=:~/src/git$ make -j 8
artagnon|maste
Merge strategy and its options can be specified in `git rebase`,
but with `--interactive`, they were completely ignored.
Signed-off-by: Arnaud Fontaine
---
git-rebase--interactive.sh| 11 ++-
t/t3404-rebase-interactive.sh | 11 +++
2 files changed, 21 insertions(+), 1 deletio
Am 6/20/2013 20:11, schrieb Junio C Hamano:
> Johannes Sixt writes:
>> But you can't have this string:
>>
>> "Splitting a commit while rebasing branch '%2$s' on '%3$s'."
>>
>> neither in the template nor in the translation, because the numbers must
>> begin at 1 (and must be used without gaps).
On Wed, Jun 19, 2013 at 02:05:06AM +0530, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
> > Sounds like making "make test" build it is a more correct approach,
> > at least to me. What am I missing?
>
> How exactly? I'm not exactly competent in make, but this is what I
> understood from w
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Among what's new in 'master' and 'next' are many code and
documentation clean-ups.
I am wondering if it may be better for the project for me to
On Fri, Jun 21, 2013 at 12:45:25AM -0400, Brian Gernhardt wrote:
> > I'm not sure if there is something different between 2.2.16 and 2.2.22,
> > or something with the particular build. Here's my -V output, in case it
> > helps:
> [...]
> Doesn't look terribly different from mine.
It turns out tha
On Jun 21, 2013, at 12:42 AM, Jeff King wrote:
> I'm not sure if there is something different between 2.2.16 and 2.2.22,
> or something with the particular build. Here's my -V output, in case it
> helps:
>
>$ apache2 -V
>Server version: Apache/2.2.16 (Debian)
>Server built: Mar 3
On Fri, Jun 21, 2013 at 12:30:52AM -0400, Jeff King wrote:
> > OS X 10.8.4, apache 2.2.22
>
> Hrm. That's quite odd. The patch in its entirety looks like this:
> [...]
> So it should not be having any effect at all on apache 2.2, unless it
> somehow does not like the tags.
Just to double-check,
I've bisected it to this commit:
> commit 0442743810c6f6c14386a5a9d6bf8e4d69adbc51
> Author: Jeff King
> Date: Sun Jun 9 04:07:59 2013 -0400
>
> t/lib-httpd/apache.conf: do not use LockFile in apache >= 2.4
OS X 10.8.4, apache 2.2.22
I'll also note that the tests fail the first time they
On Fri, Jun 21, 2013 at 12:27:02AM -0400, Brian Gernhardt wrote:
> I've bisected it to this commit:
>
> > commit 0442743810c6f6c14386a5a9d6bf8e4d69adbc51
> > Author: Jeff King
> > Date: Sun Jun 9 04:07:59 2013 -0400
> >
> > t/lib-httpd/apache.conf: do not use LockFile in apache >= 2.4
>
Mention that the command below is needed for prompt
in ZSH with PS1:
setopt PROMPT_SUBST
Make it clear that colored prompt is only available
in PROMPT_COMMAND mode.
Signed-off-by: Eduardo R. D'Avila
---
5 4 contrib/completion/git-prompt.sh
contrib/completion/git-prompt.sh | 9
The previously proposed patch set to enable color
prompt in non-PROMPT_COMMAND mode
(http://article.gmane.org/gmane.comp.version-control.git/228017)
introduce some problems with command line editing/browsing/completion,
as explained by Simon Oosthoek, in
http://article.gmane.org/gmane.comp.version-
Do not print a duplicate clean color code when there
is no other indicators other than the current branch
in colored prompt.
Signed-off-by: Eduardo R. D'Avila
---
1 1 contrib/completion/git-prompt.sh
6 6 t/t9903-bash-prompt.sh
contrib/completion/git-prompt.sh | 2 +-
t/t
__git_ps1_colorize_gitstring() sets color codes and
builds the prompt gitstring. It has duplicated code
to handle color codes for bash and zsh shells.
__git_ps1() also has duplicated logic to build the
prompt gitstring.
Remove duplication of logic to build gitstring in
__git_ps1_colorize_gitstring
git-prompt.sh lacks tests for PROMPT_COMMAND mode.
Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh
Having these tests enables an upcoming refactor in
a safe way.
Signed-off-by: Eduardo R. D'Avila
---
254 0 t/t9903-
Dennis Kaarsemaker writes:
> I'd really like to have C as well though, would you accept a patch that
> implements it?
I already said I dunno, and asking me 5 minutes after that would not
change my answer X-<. I tend to agree with Peff that it is papering
over the underlying problem, which B sol
On do, 2013-06-20 at 16:30 -0700, Junio C Hamano wrote:
> Maybe there is a miscommunication.
>
> $ git ls-remote git://github.com/git/git.git | grep remotes/
>
> shows that that repository, your origin, has refs/remotes/github/html
Yes, I misunderstood you and see the problem now. Thanks
Dennis Kaarsemaker writes:
> I'm not doing that in non-bare repositories, neither do I use it for
> pushing. It's for a continuous integration system, which never has any
> locally created branches or commits, but does integrate things from
> different remotes in some cases.
Perhaps then
Dennis Kaarsemaker writes:
>> Going back to your original example:
>>
>> [remote "origin"]
>> url = git://github.com/git/git.git
>> fetch = +refs/*:refs/*
>> mirror = true
>> [remote "peff"]
>> url = git://github.com/peff/git.git
>>
On do, 2013-06-20 at 19:08 -0400, Jeff King wrote:
> I wonder why Dennis wants to "refs/*:refs/*" in the first place. It
> is not usually a useful thing to have in a non-bare repository,
> because fetches will overwrite local work on branches. If he just
> wanted the automatic "git push --mirror"
On Thu, Jun 20, 2013 at 03:46:20PM -0700, Junio C Hamano wrote:
> Dennis Kaarsemaker writes:
>
> > When cloning a repo with --mirror, and adding more remotes later,
> > get_stale_heads for origin would mark all refs from other repos as stale. In
> > this situation, with refs-src and refs->dst bo
(Sorry, I sent v2 before seeing this mail)
On do, 2013-06-20 at 15:46 -0700, Junio C Hamano wrote:
> Dennis Kaarsemaker writes:
>
> > When cloning a repo with --mirror, and adding more remotes later,
> > get_stale_heads for origin would mark all refs from other repos as stale. In
> > this situat
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as stale. In
this situation, with refs-src and refs->dst both equal to refs/*, we should
ignore refs/remotes/* and refs/tags/* when looking for stale refs to
prevent thi
Thanks; both look obviously good.
--
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
Dennis Kaarsemaker writes:
> When cloning a repo with --mirror, and adding more remotes later,
> get_stale_heads for origin would mark all refs from other repos as stale. In
> this situation, with refs-src and refs->dst both equal to refs/*, we should
> ignore refs/remotes/* when looking for stal
From: Thomas Rast
The logic for pulling into an unborn branch was originally
designed to be used on a newly-initialized repository
(d09e79c, git-pull: allow pulling into an empty repository,
2006-11-16). It thus did not initially deal with
uncommitted changes in the unborn branch. The case of a
When commit d09e79c taught git to pull into an unborn
branch, it first updated the unborn branch to point at the
pulled commit, and then used read-tree to update the index
and working tree. That ordering made sense, since any
failure of the latter step would be due to filesystem
errors, and one cou
On Thu, Jun 20, 2013 at 06:03:28PM -0400, Jeff King wrote:
> OK. I'll prepare a series with both patches. Stand by...
Here it is:
[1/2]: pull: update unborn branch tip after index
[2/2]: pull: merge into unborn by fast-forwarding from empty tree
The first one is mine. The second is Thomas's
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as stale. In
this situation, with refs-src and refs->dst both equal to refs/*, we should
ignore refs/remotes/* when looking for stale refs to prevent this from
happening
Junio C Hamano writes:
> Like you said, I do not want to contaminate this series with such an
> unrelated change. Worse, you are trying to break a sane default by
> replacing it with "anything goes".
>
> We already have a sane default, which is to error out. We do not
> need your broken default
Hi,
On Mon, Jun 17, 2013 at 11:55:36AM +0200, Fredrik Gustafsson wrote:
> set_rev_name is a possible expensive operation. If a submodule has
> changes in it, set_rev_name was called twice.
>
> Solution is to move set_rev_name so it's only called once, no matter the
> codepath taken.
Looks good t
On Thu, Jun 20, 2013 at 02:45:04PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think I got us off-track with my expectation of ending the one case
> > with a conflicted index. But caring about that is even more unlikely. I
> > think Thomas's original patch is probably a happy mediu
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>> They're not the same thing. It is very much intentional and intended:
>>> the safety net is not to "ensure that the push and pull are
>>> symmetrical" (i.e. among other things, error out if
>>> branch.$branch.merge is unset), but rather "e
Jeff King writes:
> I think I got us off-track with my expectation of ending the one case
> with a conflicted index. But caring about that is even more unlikely. I
> think Thomas's original patch is probably a happy medium.
OK, so should I consider it Reviewed-by: peff?
> As an orthogonal matt
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Without any configuration the current branch is pushed out, which
>> loosens the safety we implemented in the current 'safer upstream'.
>>
>> I am not convinced this is a good change. I am not convinced this is
>> a bad change, either, yet, b
[git version: next as of yesterday afternoon]
If I clone a repo with git clone --mirror, and add other remotes later,
'git remote prune origin' deletes all branches and tags of the other
remotes.
Easily repeatable example:
[core]
repositoryformatversion = 0
filemode = true
Junio C Hamano wrote:
>> They're not the same thing. It is very much intentional and intended:
>> the safety net is not to "ensure that the push and pull are
>> symmetrical" (i.e. among other things, error out if
>> branch.$branch.merge is unset), but rather "ensure that the push and
>> pull are n
May be because they (LKM) are more open to such architectural and
organization refactorings?
Some maintainers, like Greg Kroah-Hartman and possibly others accept
clean up patches, such thing seems to be unacceptable here on git.
Looks like there is space here only for features and bug fixes.
Nothi
"Philip Oakley" writes:
> From: "Junio C Hamano"
> Sent: Thursday, June 20, 2013 8:23 PM
>> Ramkumar Ramachandra writes:
>>
>>> Junio C Hamano wrote:
Double negation confused my parser. 'push' and 'pull' should be
kept symmetrical in central workflows?
>>>
>>> They're not the same th
On Thu, Jun 20, 2013 at 01:49:13PM -0700, Junio C Hamano wrote:
> > But read-tree already does
> > the hard work for us, so I don't think it is a lot of code either way.
>
> OK, I just got an impression from reading the back-and-forth between
> you two that read-tree does not want to deal with th
From: "Junio C Hamano"
Sent: Thursday, June 20, 2013 8:23 PM
Ramkumar Ramachandra writes:
Junio C Hamano wrote:
Decouple `simple` from `upstream` completely, and change it to mean
`current` with a safety feature: a `push` and `pull` should not be
asymmetrical in the special case of central w
Jeff King writes:
>> Perhaps making sure the index is empty is sufficient, then?
>
> That would not let you pull when you have "foo" staged, but upstream
> does not have "foo" at all. To be fair, that is quite a corner case, and
> simply rejecting the pull entirely may be OK.
That simplicity was
Alexey Shumkin writes:
> The expected SHA-1 digests are always available in variables. Use
> them instead of hardcoding.
>
> Signed-off-by: Alexey Shumkin
> ---
> t/t4205-log-pretty-formats.sh | 48
> +++
> 1 file changed, 26 insertions(+), 22 deletions(
Alexey Shumkin writes:
> The expected SHA-1 digests are always available in variables. Use
> them instead of hardcoding.
>
> Signed-off-by: Alexey Shumkin
> ---
> t/t6006-rev-list-format.sh | 142
> +
> 1 file changed, 79 insertions(+), 63 deletions(
Alexey Shumkin writes:
Subject: Re: [PATCH v5 5/5] pretty: user format ignores i18n.logOutputEncoding
setting
That is a statement of fact, and does not tell much to the reader.
I think you are saying that in the current implementation,
logoutputencoding is not honored in user format, that it i
Alexey Shumkin writes:
> @@ -19,7 +23,8 @@ add_file () {
> echo "$name" >"$name" &&
> git add "$name" &&
> test_tick &&
> - git commit -m "Add $name" || exit
> + msg_added_iso88595=$(echo "Ad
On Thu, Jun 20, 2013 at 11:43:37AM -0700, Junio C Hamano wrote:
> Thomas Rast writes:
>
> > The logic for pulling into an unborn branch was originally designed to
> > be used on a newly-initialized repository (d09e79c, git-pull: allow
> > pulling into an empty repository, 2006-11-16). It thus d
On Thu, Jun 20, 2013 at 12:36:21PM -0700, Junio C Hamano wrote:
> > I like the latter option. It takes a non-trivial amount of time to load
> > the commits from disk, and now we are potentially doing it 2 or 3 times
> > for a run (once to parse, once to get the author info for topo-sort, and
> > p
Alexey Shumkin writes:
> Alexey Shumkin (5):
> t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
> t7102 (reset): don't hardcode SHA-1 in expected outputs
> t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs
> pretty: Add failing tests: user format ignore
Martin von Zweigbergk writes:
> On Thu, Jun 13, 2013 at 3:29 PM, Junio C Hamano wrote:
>> Ramkumar Ramachandra writes:
>>
>> A more troublesome is that nobody seems to check the return value of
>> this function. If head-name, onto or orig-head is missing, is that
>> an error condition that sho
On Thu, Jun 20, 2013 at 08:03:43PM +0200, Michael Haggerty wrote:
> > I noticed that recently, too. I have a patch series about 90% complete
> > that abstracts the tempfile handling (the ultimate goal of which is to
> > optionally clean up tmp_* files in the objects/ directory). It refactors
> > t
Jeff King writes:
>> Or we could extend parse_commit() API to take an optional commit
>> info slab to store not just author date but other non-essential
>> stuff like people's names, and we arrange that extended API to be
>> triggered when we know --author-date-order is in effect?
>
> I like the
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>> Decouple `simple` from `upstream` completely, and change it to mean
>>> `current` with a safety feature: a `push` and `pull` should not be
>>> asymmetrical in the special case of central workflows.
>>
>> Double negation confused my parser.
I would use the config feature to turn on --prune for fetch, and was
surprised that it wasn't available - I hit this thread because I figured I
somehow missed it in the config docs.
Having both global and local settings seems nice.
--
View this message in context:
http://git.661346.n2.nabble.c
"Michael S. Tsirkin" writes:
> Verify that author name is not duplicated if it matches
> sender, even if it is in utf8.
>
> Signed-off-by: Michael S. Tsirkin
> ---
Hmph. There seems to be something wrong in the original message I
received from you (look at Cc: line I have above, which was copi
Torsten Bögershausen writes:
> submodules with names using UTF-8 need core.precomposeunicode true
> under Mac OS X, set it in the TC.
I take that TC stands for test case?
> +test_expect_success 'submodule with UTF-8 name' '
> + mkdir "$svname" &&
> (
> - cd "å äö" &&
> +
Thomas Rast writes:
> The logic for pulling into an unborn branch was originally designed to
> be used on a newly-initialized repository (d09e79c, git-pull: allow
> pulling into an empty repository, 2006-11-16). It thus did not
> initially deal with uncommitted changes in the unborn branch. The
Michael Haggerty writes:
> On 06/20/2013 07:11 PM, Junio C Hamano wrote:
>
>> Perhaps I am missing something from the previous discussions, but I
>> am having trouble understanding the "main packed ref cache" part of
>> the above. "main" as opposed to...?
>
> "main" as opposed to "submodule".
I
Johannes Sixt writes:
> Am 6/20/2013 9:56, schrieb Peter Krefting:
>> Junio C Hamano:
>>
>>> But my understanding is that the reordering using printf() is the
>>> mechanism we suggest l10n folks to use when the order of parameters
>>> given to printf does not match the preferred word order in th
Richard Hansen writes:
> Barfing on non-tags is the feature this adds. It's otherwise useless,
> just like ^{object} is useless except to barf when
> doesn't exist.
Thanks.
I could buy that. And after re-reading the proposed log message,
you do not quite have anything to say that. Instead,
On 06/20/2013 01:55 PM, Jeff King wrote:
> On Thu, Jun 20, 2013 at 09:49:51AM +0200, Michael Haggerty wrote:
>
>> [I just noticed that lock_ref_sha1_basic() leaks a struct lock_file
>> every time that it is called.]
>
> I noticed that recently, too. I have a patch series about 90% complete
> that
On 06/20/2013 07:11 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> But currently only the main packed ref cache can be locked, so it would
>> be possible for lock_packed_refs() to use the static packlock instance
>> for locking.
>
> Perhaps I am missing something from the previous dis
Do you need a genuine Loan to settle your bills and start up a good
business? Kindly contact us now with your details to get a secured
Loan at a low rate of 2% per Annu, Quick send your details via:
stella.fina...@usa.com
--
To unsubscribe from this list: send the line "unsubscribe git"
Richard Hansen wrote:
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -677,6 +677,8 @@ static int peel_onion(const char *name, int len, unsigned
> char *sha1)
> sp++; /* beginning of type name, or closing brace for empty */
> if (!strncmp(commit_type, sp, 6) && sp[6] == '}')
>
Michael Haggerty writes:
> But currently only the main packed ref cache can be locked, so it would
> be possible for lock_packed_refs() to use the static packlock instance
> for locking.
Perhaps I am missing something from the previous discussions, but I
am having trouble understanding the "main
Namhyung Kim wrote:
> diff --git a/Documentation/git-send-email.txt
> b/Documentation/git-send-email.txt
> index 40a9a9a..5694d98 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -238,7 +238,7 @@ Automating
> the value of 'sendemail.identity'.
>
Hi,
On Thu, Jun 20, 2013 at 3:20 PM, Thomas Rast wrote:
> Francis Moreau writes:
>>
>> But I'm wondering if someone can see another solution more elegant ?
>
> I think there's a cute way. Suppose your arguments are of the form
Really nice !
>
> p1 p2 ... --not n1 n2 ...
>
> that is each pX
Thomas Rast wrote:
> diff --git a/git-pull.sh b/git-pull.sh
> index 638aabb..1f84383 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -266,10 +266,17 @@ case "$merge_head" in
> ;;
> esac
>
> +# Pulling into unborn branch: a shorthand for branching off
> +# FETCH_HEAD, for lazy typers.
>
Hi all,
To make it easier to help test changes that are in-flight, I've started
using and publishing daily snapshots of -next as packages for Ubuntu
12.10, 13.04 and 13.10, Debian 7.0 and Fedora 17 and 18.
If anyone else wants to use these, they can be found on launchpad and
openSUSE's build serv
submodules with names using UTF-8 need core.precomposeunicode true
under Mac OS X, set it in the TC.
Improve the portability:
Not all shells on all OS may understand literal UTF-8 strings.
Use a help variable filled by printf, as we do it in e.g. t0050.
"strange names" can be called UTF-8, rephra
Jeff King writes:
> On Thu, Jun 20, 2013 at 03:33:34PM +0200, Thomas Rast wrote:
>
>> >> I naively would have expected this to leave us in a conflicted state
>> >> over "file". But I guess read-tree just rejects it, because we are not
>> >> doing a real three-way merge. I'm not sure it is that
Thomas Rast writes:
> if test -z "$orig_head"
> then
> git update-ref -m "initial pull" HEAD $merge_head "$curr_head" &&
> - git read-tree -m -u HEAD || exit 1
> + # Two-way merge: we claim the index is based on an empty tree,
> + # and try to fast-forward to HEAD. This ensur
Francis Moreau wrote:
> Basically I have an initial set (or can be several different sets)
> expressed as a revision specification described by git-rev-list man
> page. I just want to find the common set of commit which are part of
> the initial sets *and* is reachable by master.
That's just a gen
On Thu, Jun 20, 2013 at 03:33:34PM +0200, Thomas Rast wrote:
> >> I naively would have expected this to leave us in a conflicted state
> >> over "file". But I guess read-tree just rejects it, because we are not
> >> doing a real three-way merge. I'm not sure it is that big a deal; this
> >> is m
On Thu, Jun 20, 2013 at 06:46:55PM +0530, Ramkumar Ramachandra wrote:
> So this should explain the problem:
>
> # using v1.8.3.1
> $ git clone https://google.com
> Cloning into 'google.com'...
> fatal: repository 'https://google.com/' not found
>
> # using master
> $ git clone https:
Thomas Rast writes:
> Jeff King writes:
>
>> On Thu, Jun 20, 2013 at 03:06:01PM +0200, Thomas Rast wrote:
>>
>>> +test_expect_success 'pulling into void does not overwrite staged files' '
>>> + git init cloned-staged-colliding &&
>>> + (
>>> + cd cloned-staged-colliding &&
>>> +
@Matthieu
Ok, I'm replacing with "Reset only files which actually changed (not
those with only stat information change)"
@Junio
I'm not sure what you're asking, sorry, I'm not able to understand
your question.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mes
Jeff King writes:
> On Thu, Jun 20, 2013 at 03:06:01PM +0200, Thomas Rast wrote:
>
>> +test_expect_success 'pulling into void does not overwrite staged files' '
>> +git init cloned-staged-colliding &&
>> +(
>> +cd cloned-staged-colliding &&
>> +echo "alternate cont
Francis Moreau writes:
> Hello,
>
> I'd like to write a script that would parse commits in one of my repo.
> Ideally this script should accept any revision ranges that
> git-rev-list would accept.
>
> This script should consider commits in master differently than the
> ones in others branches.
>
Hi,
So this should explain the problem:
# using v1.8.3.1
$ git clone https://google.com
Cloning into 'google.com'...
fatal: repository 'https://google.com/' not found
# using master
$ git clone https://google.com
Cloning into 'google.com'...
fatal: repository 'https://google.com/
Hi,
On Thu, Jun 20, 2013 at 3:04 PM, Phil Hord wrote:
> On Thu, Jun 20, 2013 at 6:14 AM, Francis Moreau
> wrote:
>> I'd like to write a script that would parse commits in one of my repo.
>> Ideally this script should accept any revision ranges that
>> git-rev-list would accept.
>>
>> This scrip
On Thu, Jun 20, 2013 at 03:06:01PM +0200, Thomas Rast wrote:
> +test_expect_success 'pulling into void does not overwrite staged files' '
> + git init cloned-staged-colliding &&
> + (
> + cd cloned-staged-colliding &&
> + echo "alternate content" >file &&
> +
On Thu, Jun 20, 2013 at 1:26 PM, Ramkumar Ramachandra
wrote:
> Francis Moreau wrote:
>> To get the commit set which can't be reached by master (ie commits
>> which are specific to branches other than master) I would do:
>>
>> # "$@" is the range spec passed to the script
>> git rev-list "$@" ^
The logic for pulling into an unborn branch was originally designed to
be used on a newly-initialized repository (d09e79c, git-pull: allow
pulling into an empty repository, 2006-11-16). It thus did not
initially deal with uncommitted changes in the unborn branch. The
case of an _unstaged_ untrack
On Thu, Jun 20, 2013 at 6:14 AM, Francis Moreau wrote:
> I'd like to write a script that would parse commits in one of my repo.
> Ideally this script should accept any revision ranges that
> git-rev-list would accept.
>
> This script should consider commits in master differently than the
> ones in
On Thu, Jun 20, 2013 at 02:48:15PM +0200, Thomas Rast wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Jun 20, 2013 at 02:41:37PM +0200, Thomas Rast wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > Verify that author name is not duplicated if it matches
> >> > sender, even if it is in ut
On Thu, Jun 20, 2013 at 02:36:03PM +0200, Thomas Rast wrote:
> The logic for pulling into an unborn branch was originally designed to
> be used on a newly-initialized repository (d09e79c, git-pull: allow
> pulling into an empty repository, 2006-11-16). It thus did not
> initially deal with uncomm
"Michael S. Tsirkin" writes:
> On Thu, Jun 20, 2013 at 02:41:37PM +0200, Thomas Rast wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > Verify that author name is not duplicated if it matches
>> > sender, even if it is in utf8.
>>
>> Small nit: if you make two patches out of it, add the tests firs
On Thu, Jun 20, 2013 at 02:41:37PM +0200, Thomas Rast wrote:
> "Michael S. Tsirkin" writes:
>
> > Verify that author name is not duplicated if it matches
> > sender, even if it is in utf8.
>
> Small nit: if you make two patches out of it, add the tests first with
> test_expect_failure. Then fli
"Michael S. Tsirkin" writes:
> Verify that author name is not duplicated if it matches
> sender, even if it is in utf8.
Small nit: if you make two patches out of it, add the tests first with
test_expect_failure. Then flip it to test_expect_success in the actual
code change. That makes it easy
The logic for pulling into an unborn branch was originally designed to
be used on a newly-initialized repository (d09e79c, git-pull: allow
pulling into an empty repository, 2006-11-16). It thus did not
initially deal with uncommitted changes in the unborn branch. The
case of an _unstaged_ untrack
Verify that author name is not duplicated if it matches
sender, even if it is in utf8.
Signed-off-by: Michael S. Tsirkin
---
t/t9001-send-email.sh | 14 ++
1 file changed, 14 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 9f46f22..020acc4 100755
--- a
sender is now sanitized, but we didn't sanitize
author when checking whether From: line is needed
in the message body.
As a result git started writing duplicate From lines
when author matched sender and has utf8 characters.
Reported-by: SZEDER Gábor
Tested-by: SZEDER Gábor
Signed-off-by: Michael
On Thu, Jun 20, 2013 at 09:49:51AM +0200, Michael Haggerty wrote:
> [I just noticed that lock_ref_sha1_basic() leaks a struct lock_file
> every time that it is called.]
I noticed that recently, too. I have a patch series about 90% complete
that abstracts the tempfile handling (the ultimate goal o
On Thu, Jun 20, 2013 at 11:09:49AM +0200, Michael Haggerty wrote:
> If the packed-refs file is already locked by another process (and there
> is no reason why that cannot be, and there is only one attempt to
> acquire the lock), then repack_without_ref() emits an error and returns
> with an error
Francis Moreau wrote:
> To get the commit set which can't be reached by master (ie commits
> which are specific to branches other than master) I would do:
>
> # "$@" is the range spec passed to the script
> git rev-list "$@" ^master | check_other_commit
>
> But I don't know if it's possible to
Ok, thanks for all the reviews,
Final version (I hope :) ) will come when all the mediawiki patches
will have graduated to 'master' then.
Benoit Person
--
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 h
1 - 100 of 140 matches
Mail list logo
