Hi,
Simon Ruderich wrote:
On Sun, Apr 07, 2013 at 12:46:23PM -0500, Felipe Contreras wrote:
+test_expect_success 'cover letter auto' '
+mkdir -p tmp
+test_when_finished rm -rf tmp;
[...]
I'm not sure if it's better to use test_when_finished with rm or
just rm -rf tmp at the end
Aaron Schrab wrote:
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -231,12 +231,19 @@ static void strip_trailing_slashes(char *dir)
static int add_one_reference(struct string_list_item *item, void *cb_data)
{
- char *ref_git;
+ char *ref_git, *repo;
[...]
+ repo = (char
Hi Ram,
Ramkumar Ramachandra wrote:
In my opinion,
.gitmodules is a wart that needs to be done away with: it should _not_
be on the filesystem, just like a commit object isn't on the
filesystem.
What do you think of .gitignore and
Ramkumar Ramachandra wrote:
Jens Lehmann wrote:
Hmm, at least the unstaged .gitmodules file has to be parsed from
the file system.
You seem to be touting it as a distinct advantage.
To clarify what I said in a side thread: yes, as long as the submodule
metadata includes the hostname I am
the status of the
supplied path.
Yes, makes sense.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
My only remaining qualm is that a person could be confused by the
message after trying to pass in --reference=file:///path/to/repo, but
I guess that trial and error would eventually lead such a person
-dir=L A M
+ git clone --reference=M A N
What should happen if I pass --reference=M/.git?
+ echo $base_dir/L/objects expected
The usual style in tests is to include no space after redirection
operators.
With those two changes,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Junio C Hamano wrote:
And I think now I agree that indeed is a sensible assumption. I am
not sure '-' is a good token for that, but I do not offhand think of
a reason why '-' would be a _bad_ token for that, either.
Random idea: today you can do
git push origin master; # push branch
Jonathan Nieder wrote:
today you can do
git push origin master; # push branch master to remote origin
git push --multiple origin korg; # push default refspec to 2 remotes
Pretend I said fetch. ;-)
--
To unsubscribe from this list: send the line unsubscribe git
Antoine Pelisse wrote:
Separate text formatting from size simplification and make the function
public in strbuf so that it can easily be used by other clients.
We now can use strbuf_humanize() for both downloaded size and download
speed calculation.
Sounds like a good thing to do.
Ramkumar Ramachandra wrote:
Ramkumar Ramachandra wrote:
git push -- master next; pushes to my current branch's
branch.name.pushremote? Isn't that a disaster?
Actually, branch.name.pushremote already breaks the current design
in a way
I don't see a big problem here, actually. What's so
Ramkumar Ramachandra wrote:
My point is that we should have sane
defaults, and fine-grained configurability so that uses who disagree
can maintain their own configs.
I don't agree with this principle. I like a tool that behaves sanely
with little work and that
Jeff King wrote:
On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:
git push
and [push] default = upstream, then it is obvious what the user
wanted to happen. But what about when [push] default = matching?
Which of the following behaviors is correct?
a) Error: you
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
git push master
...
a) Error: you didn't tell me which remote to push to.
b) Just behave like git push my-personal-remote master.
c) Behave like git push origin master.
Here, I'd argue for (d): push to branch.master.pushremote
Hi,
Thanks for looking it over.
Ramkumar Ramachandra wrote:
- Why are you hard-coding .gitmodules instead of using a simple #define?
Advantage of .gitmodules: it's obvious what it means.
Advantage of DOT_GITMODULES: protection against spelling errors.
Git has a lot of use of both styles of
Jeff King wrote:
Here it is with a commit message.
-- 8 --
Subject: [PATCH] daemon: set HOME when we switch to --user
Thanks for taking care of it. For what it's worth,
Acked-by: Jonathan Nieder jrnie...@gmail.com
I'm not sure whether to keep 96b9e0e (config: treat user and xdg
config
Jeff King wrote:
I could go either way. I think 96b9e0e is the right thing to do
conceptually, but I kind of doubt it was affecting all that many people.
And though it's _possible_ for it to be a security problem, I find it
much more likely that the site admin tries to set some config, gets
Hello,
João Joyce wrote:
I am not sure this is the right place to ask this.
You're in the right place.
[...]
I am trying to push some files to a server with git push. I have
configured the server to push the files:
git remote set-url test ssh://u...@location.com:2200/fullpath/
but I
/ 1000.0);
That way, the message to be translated doesn't start with a newline,
so translators don't have to worry about preserving it (or removing
it if the layout ever changes in the future, etc).
With that change,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks.
--
To unsubscribe from
Hi,
Junio C Hamano wrote:
How much of this stuff have interact with real changes that are in
flight, with various doneness cooking in different integration
branches?
All except the t3511-cherry-pick-x.sh change apply cleanly to
maint and merge without trouble with master and pu.
Here is a
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 12 Apr 2013 00:36:10 +0200
Most of these were found using Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
I like this one
...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
contrib/mw-to-git/git-remote-mediawiki.perl| 6 +++---
contrib/mw-to-git/t/README | 6 +++---
contrib/mw-to-git/t/install-wiki/LocalSettings.php | 2 +-
contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 12 Apr 2013 00:36:10 +0200
Noticed with Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
contrib/subtree/t/t7900-subtree.sh | 2
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 12 Apr 2013 00:36:10 +0200
Noticed using Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Would it be more useful to fix
...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Is gawk the appropriate upstream to send this sort of readability
improvement to?
compat/regex/regcomp.c| 4 ++--
compat/regex/regex.c | 2 +-
compat/regex/regex_internal.c | 6 +++---
3 files changed, 6 insertions(+), 6
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 12 Apr 2013 00:36:10 +0200
Noticed using Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
compat/precompose_utf8.c | 2 +-
1 file
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 12 Apr 2013 00:36:10 +0200
Correct some typos found using Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
These don't seem
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 12 Apr 2013 00:36:10 +0200
Correct spelling mistakes noticed using Lucas De Marchi's codespell
tool.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Git might
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 12 Apr 2013 00:36:10 +0200
Correct common spelling mistakes noticed by Lucas De Marchi's
codespell tool.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Split from
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 12 Apr 2013 00:36:10 +0200
Most of these were found using Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks for reading
other
than permissions.
Thanks to Mike Galbraith, W. Trevor King, and Jeff King for their
patient explanations.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Jeff King wrote:
Given how tight the exception is, I almost wonder if we should drop the
environment variable completely, and just
A cleanup from Jeff King.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
wrapper.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
Jeff King wrote:
I kind of wonder if we are doing anything with the check at this point.
I suppose ENOMEM and EIO are the only
or ~/.config/git is unreadable due to problems
other than permissions.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Improved-by: Jeff King p...@peff.net
---
Jonathan Nieder wrote:
--- a/wrapper.c
+++ b/wrapper.c
@@ -408,11 +408,16 @@ void warn_on_inaccessible(const char *path
Junio C Hamano wrote:
Just rerolling with what _you_ think is an appropriate level of
explanation (either or both in log and in-code) and see what happens
would probably be the best way to proceed, I think, at this
point. Either you hear It still is wrong and too sketchy, Yeah,
thinking
Jeff King wrote:
I was also tempted to suggest just dropping the recursion check
altogether. While it is neat to detect such things, it's a should never
happen bug situation, and an infinite loop of printing out the same
message is pretty easy to notice.
On servers it might be useful to
Jeff King wrote:
--- a/run-command.c
+++ b/run-command.c
@@ -603,7 +603,7 @@ static NORETURN void die_async(const char *err, va_list
params)
{
vreportf(fatal: , err, params);
- if (!pthread_equal(main_thread, pthread_self())) {
+ if (!running_main_thread()) {
Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
That changing the meaning of name in the middle, and doing so
will be confusing to the users, is exactly the issue, isn't it?
Yes, but we have to change _something_ if we don't want to hit a WTF
like 'git push master next' pushing master and
Jonathan Nieder wrote:
As you hinted before, this would involve reverting the introduction
of branch.name.pushremote, with the explanation that it was a
mistake inspired by that false symmetry, that you noticed and were
uncomfortable with but the rest of us were blind too.
s/too
) :
+_(Branch %s set up to track remote branch %s
from %s.\n),
Micronit: it would be nicer to use printf_ln to save translators the
trouble of worrying about the final newline.
With that change,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks. Here's a patch making that change
Ramkumar Ramachandra wrote:
When set,
instead of cloning the given repository as-is, it relocates the gitdir
of the repository to the path specified by this variable.
Interesting. As the discussion downthread from this illustrated, I am
Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com writes:
Yes, that is why I said for pull-merge, --authsquash is neutral-to-better
and pull.autosquash is harmful.
To speak from my experience: I find myself typing git stash git pull
git stash pop relatively often.
To that end, maybe
Ramkumar Ramachandra wrote:
Matthieu Moy wrote:
No, you don't. Just try if you're not convinced:
Oh, I trusted the documentation on this one and never tried with a
dirty worktree myself. Please fix the documentation, if you know how
exactly to correct it.
The manual says:
git
Ramkumar Ramachandra wrote:
If there were uncommitted worktree changes present when the merge
started, git merge --abort will in some cases be unable to reconstruct
these changes. It is therefore recommended to always commit or stash
your changes before running git merge.
Matthieu (and
Junio C Hamano wrote:
Sverre Rabbelier srabbel...@gmail.com writes:
Perhaps it makes sense to instead count the number of signed tags and
emit Stripped signature from %d tags? For example, for git.git it
would be on the order of a hundred warning lines.
When you see 78 in the output and you
Drew Northup wrote:
This is unobtrusive yet to the point.
I agree with the spirit.
[...]
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -55,7 +55,8 @@ following order:
then fallback system-wide configuration file (defaults to
worse and even should make them easier to fix
later, so
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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
Ramkumar Ramachandra wrote:
2. This ugliness complicates implementation of add/ rm/ mv, because
each of them will have to know about this contrived path solution.
Why is that? Can't they look at the gitfile or call some helper
(that happens to be part of the same binary)?
--
To unsubscribe
Hi,
Torsten Bögershausen wrote:
Git respects PYTHON_PATH, hg does not.
Probably more relevant is that contrib/remote-helpers/git-remote-hg
has a shebang line of #!/usr/bin/env python and hence does not
respect PYTHON_PATH.
Use python instead of $PYTHON_PATH to check for installed modules.
Junio C Hamano wrote:
You ran 'git add' with neither '-A (--all)' or '--no-all', whose
behaviour will change in Git 2.0 with respect to paths you
removed from your working tree.
* 'git add --no-all pathspec', which is the current default,
ignores paths you removed from
Hi Ilya,
Ilya Basin wrote:
1) a created a git repo from a foreign source using git fast-import
2) new commits were added to the foreign source
Can I create a fast-import input stream not containing the commits
already existing in my git repo and import it?
Yes, if the foreign source is
Hi,
Ramkumar Ramachandra wrote:
However, I don't understand why we
maintain it, because there's a comprehensive first-class completer in
ZSH core [1] which I use all the time. Shouldn't the completion folks
be contributing to this instead?
Only if they want to.
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
However, I don't understand why we
maintain it, because there's a comprehensive first-class completer in
ZSH core [1] which I use all the time. Shouldn't the completion folks
be contributing to this instead
Johan Herland wrote:
The DWIM mode of checkout allows you to run git checkout foo when there is
no existing local ref or path called foo and there is exactly one remote
with a remote-tracking branch called foo.
Thanks for testing this. I'm surprised no one suggested a test since
Jeff King wrote:
On Fri, Apr 19, 2013 at 08:21:48PM +0800, Nazri Ramliy wrote:
Often I find myself needing to find out quickly the status of a repository
that
is not in my currenct working directory, like this:
$ (cd ~/foo; git log -1)
With this patch now i can simply do:
Ramkumar Ramachandra wrote:
First, since and until are ways to specify revisions, not
commits, as gitrevisions.txt would indicate.
What's the difference between a revision and a commit? The definition
in gitglossary(7) only confuses me.
--
To unsubscribe from this list: send the line
Junio C Hamano wrote:
But a _real user_ who wants to use a slash there has no way of doing
so.
Doesn't foo=// do that in the msys world? If I am reading
mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to pass
a true double-slash is foo=///.
Jonathan
--
To unsubscribe from this
Hi,
William Giokas wrote:
$ git clone /tmp/foo:bar/baz /tmp/new-baz
but running this gives me this output::
Cloning into 'new-baz'...
ssh: Could not resolve hostname /tmp/foo: Success
fatal: Could not read from remote repository.
Here's a toy patch. I haven't thought
Johannes Sixt wrote:
Am 21.04.2013 02:05, schrieb Jonathan Nieder:
Junio C Hamano wrote:
But a _real user_ who wants to use a slash there has no way of doing
so.
Doesn't foo=// do that in the msys world? If I am reading
mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way
: --ignore-removals is the default but this will change soon
hint: see git-add(1) for details
Then the --ignore-removals option could be added using a patch like
the following.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Documentation/git-add.txt | 24
Ramkumar Ramachandra wrote:
What's so confusing about it?
[...]
revision:: A particular state of files and directories which was
stored in the object database. It is referenced by a commit object.
So a revision is a tree? (one of the things pointed to by a commit
object, representing a
Ramkumar Ramachandra wrote:
I would say the most technically accurate
description of what 'git log' takes is a committish range (basically
a revision range that resolves to commits).
What is a revision range that doesn't resolve to commits? Am I wrong
in thinking
Ramachandra artag...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Junio C Hamano wrote:
On Apr 21, 2013 12:41 AM, Jonathan Nieder jrnie...@gmail.com wrote:
revision:: A particular state of files and directories which was
stored in the object database. It is referenced
Ramkumar Ramachandra wrote:
Yes. If master@{3}~2:README isn't a revision, what is it?
An extended SHA1 expression referring to a blob.
--
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
John Tapsell wrote:
I'm concerned that noone is taking this security risk seriously.
If anyone relies on git log -p or git log -p --cc output to make
sure that the untrusted code they use doesn't introduce unwanted
behavior, they are making a serious mistake. A merge can completely
undo
Hi,
Michael Haggerty wrote:
This series consists of a single patch that adds a directory
contrib/hooks/git-multimail/ containing five files, described in the
patch's commit message.
Yay! I look forward to seeing it.
[...]
The first of these commits
Michael Haggerty wrote:
Add git-multimail, a tool for generating notification emails for
pushes to a Git repository. It is largely plug-in compatible with
post-receive-email, and is proposed to eventually replace that script.
The advantages of git-multimail relative to post-receive-email are
Jeff King wrote:
I don't think that is enough. Something like /path/to/foo:bar would
trigger !is_url already, but then git_connect fails.
Doh. Here's another try, still untested.
diff --git i/connect.c w/connect.c
index 49e56ba3..fe13942f 100644
--- i/connect.c
+++ w/connect.c
@@ -504,6
Hi,
Ramkumar Ramachandra wrote:
The --follow feature can be used to follow the history of a file over
a merge commit, and is useful even when the file hasn't been
copied/renamed. Add a test to show off this feature.
I can't claim to have followed the discussion, but I don't understand
the
Hi,
Ramkumar Ramachandra wrote:
A..B and A...B do not correspond to the meaning
specified in gitrevisions.txt. There's a note in the documentation
saying this, but I'm very unhappy.
What would it mean for A..B to be treated as a revision range?
Suppose I do a revision
Ramkumar Ramachandra wrote:
In DESCRIPTION, the 'commit..commit' form refers to the previous
form, namely the 'commit commit' form. However, bd52900
Good catch.
[...]
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -11,8 +11,8 @@ SYNOPSIS
[verse]
'git diff'
Ramkumar Ramachandra wrote:
It is imperative to specify options with the [options] template.
Why is it imperative?
Anyway, this looks like a good change. With that sentence removed
or some other clarification,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list
Ramkumar Ramachandra wrote:
Hm, I thought it improves readability. I'm trying to say that -- is
used to separate [path...] from [everything else].
I agree with the goal, but I don't think this change achieves it.
Maybe adding gitcli(7) to the SEE ALSO section would work?
Jonathan
--
To
Ramkumar Ramachandra wrote:
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -13,6 +13,8 @@ SYNOPSIS
'git diff' [options] --cached [commit] [[--] [path...]]
'git diff' [options] blob blob
'git diff' [options] commit commit [[--] [path...]]
+'git diff' [options]
Ramkumar Ramachandra wrote:
The form is a special case of
the first form where the number of paths are limited to two. Besides,
isn't that how the DESCRIPTION section explains it now?
Sort of. It's a completely different form, but when --no-index is
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
Maybe it would make sense to move towards eliminating the implicit
--no-index for paths outside the repository trick. I use git diff
--no-index all the time, but I always spell it out to be careful.
Huh? Why do you want to endure the pain
Junio C Hamano wrote:
And it does not match git log origin...HEAD which gives both sides
of the symmetric difference of the history. To match it, you have
to say git log --right-only origin...HEAD or something.
I tend to use --left-right. All I meant is that with both diff and
log, ... is a
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
Oh please no.
If I understand this correctly, you are horrified by this?
https://github.com/artagnon/dotfiles/blob/master/.gitconfig#L30
Nope, that looks like a useful way to save typing, and git help
helpfully expands any of your custom
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
Because typing paths does not make my intent perfectly clear.
I'm not able to understand this. Doesn't your prompt tell you which
directory you're in, and if you're in a git repository? When you type
out paths, you know what is inside
Ramkumar Ramachandra wrote:
I completely disagree, but we don't have to agree: make it a
configuration variable.
I thought we had discussed before how every configuration variable
costs quite a lot in terms of Git's teachability.
What would that configuration variable even mean? Set this to
Ramkumar Ramachandra wrote:
I thought ^@ was invented for scripting, but can't imagine a usecase for ^!.
I use git diff $commit^! from time to time to get the diff between a
merge and its first parent.
For comparison, I haven't found ^@ or git log $commit^! useful. The
commit introducing the
Junio C Hamano wrote:
At the point of calling warn_pathless_add(), it seems that we are
triggering this for paths that are not necessarily modified when run
with add -n -u.
Do you mean files that were touched but have no content change, or
something more subtle?
--
To unsubscribe from this
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Do you mean files that were touched but have no content change, or
something more subtle?
[...]
Ahh, I haven't run anything under the debugger yet, but I think I
know what is going on.
Don't we limit our update-index
(REFRESH_QUIET);
I think you mean if (implicit_dot prefix). :)
This strategy is much less invasive than the alternatives discussed,
so for what it's worth, with that correction,
Acked-by: Jonathan Nieder jrnie...@gmail.com
I'll try to get time to work on those promised tests this weekend
Hi,
Ramsay Jones wrote:
--- a/compat/nedmalloc/malloc.c.h
+++ b/compat/nedmalloc/malloc.c.h
@@ -484,6 +484,10 @@ MAX_RELEASE_CHECK_RATE default: 4095 unless not
HAVE_MMAP
#define DLMALLOC_VERSION 20804
#endif /* DLMALLOC_VERSION */
+#if defined(linux)
+#define _GNU_SOURCE 1
Ramsay Jones wrote:
After this change, it should be possible to drop the
CYGWIN_V15_WIN32API setting without any negative effect.
[rj: %s/NATIVE_WINDOWS/GIT_NATIVE_WINDOWS/g ]
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Yay
to date.
With or without a few words of explanation in the commit message to
save some time for the next confused person looking this over,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Never-mind, now I see the difference, still, I don't think it's
relevant for this patch.
I don't either. With the precedence of @{u}, @ does not need to have
anything to do with a reflog. It is just a random letter
Vikrant Varma wrote:
If origin/foo exists, but foo doesn't:
$ git merge foo
fatal: foo - not something we can merge
This patch series improves the error message. If a remote branch exists
with the same name, it now says:
$ git merge foo
fatal: foo - not something we can
Nguyễn Thái Ngọc Duy wrote:
git rev-parse 1234 will
resolve refs/heads/1234 if exists even if there is an unambiguous
SHA-1 starting with 1234. However if it's full SHA-1, the SHA-1 takes
precedence and refs with the same name are ignored.
That's
Ramkumar Ramachandra wrote:
[1]: https://www.ohloh.net/p/git/factoids#FactoidCommentsLow
Since this has been coming up from time to time:
I have nothing against including helpful comments where appropriate.
But one aspect which that factoid misses is that git has some very
detailed, very dense
Hi,
Heiko Voigt wrote:
--- a/connect.c
+++ b/connect.c
@@ -49,6 +49,16 @@ static void add_extra_have(struct extra_have_objects
*extra, unsigned char *sha1
extra-nr++;
}
+static void die_initial_contact(int got_at_least_one_head)
+{
+ if (got_at_least_one_head)
+
Dimitar Bonev wrote:
@ThomasRast: 'git show HEAD:targetfile targetfile' was proposed in
the both links that I provided in the email that your replied to, but
this introduces external dependency to the command interpreter to
output the file unmodified but not every interpreter does this.
Martin Langhoff wrote:
On Sat, May 4, 2013 at 3:34 AM, Johannes Sixt j...@kdbg.org wrote:
Since git 1.8.0 you can express this check as
if git merge-base --is-ancestor $production_sha1 refs/heads/master
Ah, that's great! Unfortunate it's not there in earlier / more widely
used releases
Thomas Rast wrote:
Junio C Hamano gits...@pobox.com writes:
* jn/config-ignore-inaccessible (2013-04-15) 1 commit
- config: allow inaccessible configuration under $HOME
When $HOME is misconfigured to point at an unreadable directory, we
used to complain and die. This loosens the check.
lexgrog(1) relies on the NAME section to find a manpage's subject's
name and description for easy access later using man -k. Add the
section it expects.
Noticed using lintian.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi Eric,
Just noticed this by running a tool to sanity-check my
Hi,
Michael Hunley wrote:
Ok, we can filter that out. But worse is that actual errors in a pull
request are sent to stdout instead of standard error. For example,
merge conflicts or pull failures because you have unstaged changes.
Yes, errors and progress output should go to stderr. The
Ramkumar Ramachandra wrote:
Quite frankly, I think -v is completely useless; who likes to scroll
through pages of terminal output?
I use -v -i together quite frequently when debugging. I also use
-v automatically to debug test failures when tests are invoked
automatically on machines I do not
Ramkumar Ramachandra wrote:
Can we do better by not printing the -v
output of the passing tests though?
Not for my use. The output from comprable tests before is often
useful for comparison. I wouldn't be against such an option for
people who want it, though.
stamps and so the more natural check by extraction
is a better fit because it focuses on the interesting aspect, namely
the absence of any archive entries.
With or without such a change,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Would it make sense to define HEADER_ONLY_TAR_OK
Paul Mackerras wrote:
I thought I had replied to this patch; maybe I only thought about it.
Given that we already have a selector to choose between exact and
regexp matching, it seems more natural to use that rather than add a
new selector entry. Arguably the IgnCase option should be
1101 - 1200 of 2895 matches
Mail list logo
