Mark Levedahl wrote:
However, I don't understand why git would need to consume its own
output - If named pipes are really needed to use git-svn because
git-svn depends upon git feeding the same git process, then that
package should not be available on cygwin or any other platform that
does
Torsten Bögershausen wrote:
Disabling PIPE under cygwin seems to be the right thing to do,
or do I miss something ?
If fifos don't work on Cygwin, disabling that test prerequisite
is defintely the right thing to do. I was taking the opportunity to
find out whether and how git could be tweaked
Hi,
Richard Hartmann wrote:
Spawning a new subprocess for every line printed is inefficient.
Use heredoc, instead.
I think this makes sense as a code clarity, simplicity, and
internationalizability improvement, but don't like the precedent of
eliminating 'echo' for the sake of fork removal
Richard Hartmann wrote:
Now that we're using heredoc, the message can span the full 80 chars.
The output is going to a console and not an email, so makes sense. :)
Verbatim copy of 634709b489bb3db79f59127fd6bf79c5fd9b5ddf in original
patch series from 2013-06-10.
As in patch 1, please drop
Richard Hartmann wrote:
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -80,7 +80,8 @@ causes the 'git commit' to abort.
The default 'pre-commit' hook, when enabled, catches introduction
of lines with trailing whitespaces and aborts the commit when
-such a line is
Richard Hartmann wrote:
The example assumes 8-char wide tabs and breaks for people with
4-char wide tabs. Convert all of those tabs to whitespace, instead.
Makes sense --- we cannot assume much about the end-user's editor
setup used to look at sample hooks.
Thanks.
--
To unsubscribe from this
Richard Hartmann wrote:
The other hooks use two whitespace for indentation instead of tabs
to signify code in the example/echo output.
Follow the same layout in templates/hooks--pre-rebase.sample
I don't understand the point of this one. Is it just consistency for
the sake of consistency?
Richard Hartmann wrote:
fwiw, I replaced my one single echo with heredoc as you
suggested I do that. I don't mind undoing that, or I can drop it from
this series altogether.
Guidance would be appreciated. :)
Thanks for your work, and no problem.
Both Junio's and my responses were
Johannes Sixt wrote:
Sorry, IMO, this goes into a totally wrong direction, in particular, I
think that this is going to close to door to make --lockref the default
some day in a way that helps everyone.
Would a '*' that acts like --lockref on a per ref basis address your
concerns?
I realize
Jonathan Nieder wrote:
Johannes Sixt wrote:
Sorry, IMO, this goes into a totally wrong direction, in particular, I
think that this is going to close to door to make --lockref the default
some day in a way that helps everyone.
Would a '*' that acts like --lockref on a per ref basis address
Hi,
Stefan Beller wrote:
addr doesn't need to be checked at that line as it it already accessed
7 lines before in the if (addr-sa_family).
Good catch. This asymmetry has been present since the lines were first
introduced (all guarded by if (addr)) in v1.4.1-rc1~3^2~4 (Log peer
address when
Stefan Beller wrote:
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
Thanks. That was quick. :)
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
Stefan Beller wrote:
[Subject: diff-no-index: Remove unused variable.]
[...]
--- a/diff-no-index.c
+++ b/diff-no-index.c
[...]
- else if (!strcmp(argv[i], -q)) {
+ else if (!strcmp(argv[i], -q))
- options |= DIFF_SILENT_ON_REMOVED;
, graph_width,
max_change);
+ int total = scale_linear(add + del, graph_width,
max_change);
Yeah, we should have caught this in review.
Thanks for reporting.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git
Tony Finch wrote:
The rss_logo CSS style has a fixed width which is too narrow for
the string OPML. Replace the fixed width with horizontal padding
so the text fits with nice margins.
Sounds sensible. Can we have your sign-off? (Likewise for the next
patch.)
Thanks,
Jonathan
--
To
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Then I will use
(5c) git push --force
which means not to use this new lockref trick that looks at my
remote-tracking branch and instead to just force the ref update.
I am not sure I follow. Do other contributors
be surprised if it is possible to improve this in some
way or other, but where as usual Reviewed-by means If I were
maintainer I would commit and push it out and as a non maintainer
I vouch for its suitability,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
The patch integrates it into the git tree
Michael Haggerty wrote:
Add a notice to the top of post-receive-email explaining that the
script is no longer under active development and pointing the user to
git-multimail.
I think the spirit of this patch is sane. Some thoughts on wording:
[...]
--- a/contrib/hooks/post-receive-email
Stefan Beller wrote:
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
Markup and methodology look correct.
Fwiw,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Is this meant to be squashed with 94b410bb (.mailmap: Map email
addresses to names, 2013-07-12)?
Ciao,
Jonathan
Greg Troxel wrote:
Alternatively, is there somewhere a first-principles analysis vs POSIX
specs (such as fsyncing object files before updating refs to point to
them, which I realize has performance negatives)?
You might be interested in the 'core.fsyncobjectfiles' setting.
git-config(1) has
forget to do more
cleanup as a followup, feel free to kick me.
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
Matthieu Moy wrote:
All options that trigger a patch output now override --no-patch.
The case of --binary is particular as the name may suggest that it turns
Usage nit: this should say is unusual or In the case of --binary in
particular, the name may suggest
a normal patch into a
Ramsay Jones wrote:
One of the three gcc compilers that I use does not understand the
sentinel function attribute. (so, it spews 108 warning messages)
Do you know what version of gcc introduced the sentinel attribute?
Would it make sense for the ifdef in git-compat-util.h to be keyed on
Matthieu Moy wrote:
This is the convention in other files and even at the beginning of git-log.txt
The docs aren't so consistent on this, but I agree that it makes sense
to at least be consistent within the generated git-log.html. :)
Generally the series looks very good. Thanks for taking
Matthieu Moy wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Matthieu Moy wrote:
All options that trigger a patch output now override --no-patch.
The case of --binary is particular as the name may suggest that it turns
Usage nit: this should say is unusual
I don't get it. The point
| 30 ++--
t/t4000-diff-format.sh | 48
+++---
6 files changed, 75 insertions(+), 28 deletions(-)
Thanks! I think this series is ready now.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe
tr...@inf.ethz.ch
---
This and the next one are message changes for things I found during my
review.
Thanks. It's nice when translation results in the messages in English
being improved, too.
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list
Thomas Rast wrote:
The existing description reads as if it somehow applies a filter.
Change it to explain that it is merely about the ordering.
[...]
OPT_SET_INT(0, date-order, sort_order,
- N_(show commits where no parent comes before its
+
Dirk Wallenstein wrote:
Those text files are installed as documentation (at least on my distribution).
That's probably a distribution bug (or a git makefile bug, depending
on how you look at it). It would be better to ship the HTML
documentation, converted to text, instead of keeping the
Mark Levedahl wrote:
Subtests 6,7, and 9 of t3032 fail on Cygwin, and I presume will fail
on msysgit for similar reasons. Looking at test 6, the expected
result is a line ending with \r\n in text.txt. This line is
extracted with grep (grep 'justice and holiness' text.txt actual),
with
Mark Levedahl wrote:
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. Change the particular whitespace
sequences to be ones that are not known line endings so the whitespace
is not changed when being extracted by line oriented grep.
(cc-ing Eric Wong, who maintains git-svn and knows both it and
the libsvn perl bindings much better than I do)
Kyle J. McKay wrote:
David Rothenberger daver...@acm.org has determined the cause to
be that ra_serf does not drive the delta editor in a depth-first
manner [...]. Instead, the calls
Kyle J. McKay wrote:
That change was made as a result of this feedback:
On Jul 6, 2013, at 17:11, Jonathan Nieder wrote:
Kyle McKay wrote:
The temp_is_locked function can be used to determine whether
or not a given name previously passed to temp_acquire is
currently locked.
[...]
+=item
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks for a pleasant patch.
Jonathan
--
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:
We should remove the support for -q in Git 2.0.
No. I hope you are teasing.
I don't mind seeing support for -q dropped, but I really don't think
it's worth delaying git 2.0 for that. Would s/in Git 2.0/in some
future release/ be ok?
The patch text itself looks
Junio C Hamano wrote:
It seems to apply well on the tip of jk/gcc-function-attributes.
- This macro is not about git at all, so I'll edit the patch to
call it GCC_ATTR_SENTINEL before applying.
Would naming it something like LAST_ARG_MUST_BE_NULL instead make
sense? That way, if some
Stefan Beller wrote:
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -9,7 +9,7 @@ SYNOPSIS
[verse]
'git reset' [-q] [tree-ish] [--] paths...
-'git reset' (--patch | -p) [tree-sh] [--] [paths...]
+'git reset' (--patch | -p) [tree-ish] [--] [paths...]
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
I don't mind seeing support for -q dropped, but I really don't think
it's worth delaying git 2.0 for that. Would s/in Git 2.0/in some
future release/ be ok?
I do not think keeping the support for -q in is any huge burden.
We
Mark Levedahl wrote:
After merging the following into current pu, all tests that run by
default pass on Cygwin 1.7, i.e.
prove -j 8 t[0-9]*.sh
reports All tests successful.
I've *never* had this happen on Cygwin before.
Nice. Thanks for your hard work.
--
To unsubscribe from this list:
Jeff King wrote:
then smart HTTP works fine. I wonder if there is a problem in the cgit
setup on kernel.org (or if it was even intended that you could fetch
from the cgit URL at all; the cgit page shows the clone URLs in
/pub/scm/git).
I didn't think cgit URLs were meant to be clonable, but
tags are meant
+for private or temporary object labels. For this reason, some git
+commands for naming objects (like `git describe`) will ignore
+lightweight tags by default.
Very readable, and I think this is a good start.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Eventually
Hi,
Stefan Beller wrote:
--- a/git.c
+++ b/git.c
@@ -309,9 +309,18 @@ static int run_builtin(struct cmd_struct *p, int argc,
const char **argv)
return 0;
}
+static int compare_internal_command(const void *a, const void *b) {
+ /* The first parameter is of type char*
Jeff King wrote:
Your patch is just swapping out git reset for cherry-pick --abort,
so I think that is a good improvement in the meantime.
Um, wasn't the idea of the original message that you can run git
reset and then git cherry-pick --continue?
Confused,
Jonathan
--
To unsubscribe from this
Jeff King wrote:
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -63,8 +63,14 @@ N_(The previous cherry-pick is now empty, possibly due to
conflict resolution.\
If you wish to commit it anyway, use:\n
\n
git commit --allow-empty\n
+\n);
+static const char
Hi,
David Aguilar wrote:
--- a/imap-send.c
+++ b/imap-send.c
@@ -22,14 +22,11 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include cache.h
-#include exec_cmd.h
-#include run-command.h
-#include prompt.h
#ifdef NO_OPENSSL
typedef void
Junio C Hamano wrote:
Is that accurate? My impression has been:
The documentation liberally mixes US and UK English (en_US/UK)
norms for spelling and grammar, which is somewhat unfortunate.
In an ideal world, it would have been better if it consistently
used only one and
Hi Joey,
Joey Hess wrote[1]:
Commit c334b87b30c1464a1ab563fe1fb8de5eaf0e5bac caused a reversion in
git-cat-file --batch.
With an older version:
joey@gnu:~/tmp/rrrgit cat-file --batch
:file name
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 blob 0
With the new version:
Junio C Hamano wrote:
Here is what is on top of the revert that has been pushed out on
'pu'.
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
[...]
To remain backwards compatible, we cannot split on whitespace by
default, hence we will ship 1.8.4 with the commit reverted
syntax as --encoding[=encoding] since it
was first documented. Clarify by removing the extra brackets.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Documentation/git-rev-list.txt | 2 +-
Documentation/pretty-options.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
I'm not thrilled with the wording. This can probably be explained
more simply. Ideas?
Documentation/pretty-options.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-options.txt b
Gerrit Pape (1):
hooks/post-receive-email: set declared encoding to utf-8
Jonathan Nieder (2):
hooks/post-receive-email: use plumbing instead of 'git log' and 'git show'
hooks/post-receive-email: force log messages in UTF-8
contrib/hooks/post-receive-email | 15 +--
1 file changed, 9
', no change in output intended.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
contrib/hooks/post-receive-email | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 15311502..72084511 100755
-by: Jonathan Nieder jrnie...@gmail.com
---
That's the end of the series. Thanks for reading.
contrib/hooks/post-receive-email | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index ba93a0d8..8ee410f8 100755
--- a/contrib/hooks/post
the email to get the best chance of a comprehensible
single-encoding email.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
contrib/hooks/post-receive-email | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post
Hi,
Dale R. Worley wrote:
Commit 52749 fixes a bug regarding testing the return of an open()
$ git show 52749
fatal: ambiguous argument '52749': unknown revision or path not in the working
tree.
Could you mention its subject line or date so it's easier to find?
call for success/failure.
Daniel Convissor wrote:
All is not lost. Your local files should be stored in the repository's
reflog. Examine the output of git reflog. You can then reset your
working directory to obtain those files by doing something _like_
git reset --hard HEAD@{1}.
Adam hadn't made a commit, so that
Daniel Convissor wrote:
On Sat, Aug 03, 2013 at 09:14:59AM +0200, Andreas Schwab wrote:
Use git remote set-branches to change the tracked branches of a
remote. Use git branch --set-upstream-to to change the upstream of a
branch (or create a new branch from the new upstream).
Thanks. Those
brian m. carlson wrote:
cmd_summary reads the output of git diff, but reads in the submodule
path into a variable called name. Since this variable does not
contain the name of the submodule, but the path, rename it to be
clearer what data it actually holds.
Nice.
Reviewed-by: Jonathan
brian m. carlson wrote:
git status prints information for submodules, but it should ignore the status
of
those which have submodule.name.ignore set to all. Fix it so that it does
properly ignore those which have that setting either in .git/config or in
.gitmodules.
Signed-off-by: brian
Alexey Shumkin wrote:
On Fri, Aug 02, 2013 at 04:23:38PM -0700, Jonathan Nieder wrote:
1. Log messages use the configured log output encoding, which is
meant to be whatever encoding works best with local terminals
(and does not have much to do with what encoding should be used
Hi Thorsten,
Thorsten Glaser wrote[1]:
git config user.email SHOULD NOT default to $(id -un)@$(hostname -f)
because just too many cow-orkers seem to be unable to follow basic
instructions
Heh.
Can you say a little more about your setup? In a university
environment with sysadmin-managed
Hi,
From a quick search for homepages:
Stefan Beller wrote:
[...]
+# The 2 following authors are probably the same person,
+# but both emails bounce.
+Amos Waterland a...@rossby.metr.ou.edu
+Amos Waterland a...@us.ibm.com
From the history of
Jeff King wrote:
Yeah, there are basically three levels of ident:
1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.
2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn
but use it.
3. It looks obviously bogus (e.g., we do not have a domain
Jeff King wrote:
Sorry to be unclear. I meant that treating /etc/mailname and gethostname
differently might be justified on Debian under the logic if you have
/etc/mailname, that is a trustworthy address, and if you do not, then we
cannot guess at a trustworthy address (because putting it in
Matthieu Moy wrote:
That would mean executing SOMETEXTTOEXECUTE each time the config file is
read. This raises two issues:
* A security issue, as SOMETEXTTOEXECUTE could also be something
dangerous. It would not be much worse than the current situation (if
your config file is not
brian m. carlson wrote:
module_name uses whatever's in .gitmodules. I'm not sure what you mean
by renamed a submodule, since git mv foo bar fails with:
vauxhall ok % git mv .vim/bundle/ctrlp .vim/bundle/ctrlq
fatal: source directory is empty, source=.vim/bundle/ctrlp,
David Jeske wrote:
Ephemeral branch names would be
local-only and would never be pushed.
That's how normal branch names behave (local branch names and remote
branch names live in different namespaces). How would the proposed
detached HEAD replacement compare
Hi,
Steffen Prohaska wrote:
--- a/wrapper.c
+++ b/wrapper.c
@@ -139,6 +139,14 @@ ssize_t xread(int fd, void *buf, size_t len)
{
ssize_t nr;
while (1) {
+#ifdef __APPLE__
+ const size_t twoGB = (1l 31);
+ /* len = 2GB immediately fails on Mac OS X
Stefano Lattarini wrote:
Why not encourage the use of a standardized '--action' option instead?
Because it's an unpleasant UI. :)
This can work with lesser compatibility headaches for both the commands
taking mode options and the commands taking mode words:
git submodule init becomes
Kyle J. McKay wrote:
According to POSIX [1] for read:
If the value of nbyte is greater than {SSIZE_MAX}, the result is
implementation-defined.
Sure.
[...]
Since OS X still supports running 32-bit executables, and SSIZE_MAX is 2GB -
1 when running 32-bit it would seem the same limit has
Hi Paul,
Paul Gortmaker wrote:
OK, so given your feedback, how do you feel about a patch to the
documentation that indicates to use -v in combination with the
--check to get equivalent patch --dry-run behaviour?
Sounds like a good idea to me.
I assume you mean a note in the OPTIONS or
Stefan Beller wrote:
On 08/20/2013 03:31 PM, Johannes Sixt wrote:
+packdir = mkpathdup(%s/pack, get_object_directory());
+packtmp = mkpathdup(%s/.tmp-%d-pack, packdir, getpid());
Should this not be
packdir = xstrdup(git_path(pack));
packtmp =
Stefan Beller wrote:
On 08/20/2013 03:31 PM, Johannes Sixt wrote:
Stefan Beller wrote:
+packdir = mkpathdup(%s/pack, get_object_directory());
+packtmp = mkpathdup(%s/.tmp-%d-pack, packdir, getpid());
Should this not be
packdir = xstrdup(git_path(pack));
packtmp =
Stefan Beller wrote:
I think I got all the suggestions except the
use of git_path/mkpathdup.
I replaced mkpathdup by mkpath where possible,
but it's still not perfect.
No, mkpathdup is generally better unless you know what you're doing.
I'll wait for the dokumentation patch of Jonathan,
Jeff King wrote:
I kind of hate the name --ulong. I wanted to call it --size or
something and abstract away the actual platform representation, and just
make it big enough for file sizes.
Yes, something like --size would be more pleasant.
It could still use unsigned long internally. My only
Jeff King wrote:
I added a test. It would not fail on existing 32-bit systems, but would
on existing LP64 systems. It will pass with the new code on both.
However, it will fail on ILP64 systems (because their int is large, and
can represent 3GB). I'm not sure if any such systems are in wide
Jeff King wrote:
I almost sent it as --size with unsigned long internally. But try
writing the documentation for it. You want to say something like it's
big enough to handle file sizes. Except that on 32-bit, it's _not_.
It's only 4G.
You really want something that uses off_t internally, so
Jeff King wrote:
On Tue, Aug 20, 2013 at 09:38:41PM -0700, Jonathan Nieder wrote:
That is what I was trying to get at in discussing the test. It is not
We would like --int to reject values higher than this, but some
platforms do not allow us to, but Either rejecting this value, or
even
Hi,
Stefan Beller wrote:
[PATCH] repack: rewrite the shell script in C.
Thanks for your work so far. This review will have mostly cosmetic
notes. Hopefully others can try it out to see if the actual behavior
is good.
As a first nit: in git, as usual in emails, the style in subject lines
is
Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
The motivation of this patch is to get closer to a goal of being
able to have a core subset of git functionality built in to git.
That would mean
* people on Windows could get a copy of at least the core parts
of
Hi,
Kacper Kornet wrote:
This is a set of fixes for problems found while running
test suite without perl installed.
I don't think git ever supported that. The PERL prerequisite
was to check for systems that did not have (a suitable) perl
at runtime, but perl is still pretty heavily used in
echo bong file
git add file
test_when_finished git reset --hard
test_must_fail git commit -C bogus
to avoid interfering with later tests even when this one fails and
the prevents the 'git reset' from being executed.
With or without that change,
Reviewed-by: Jonathan
.
Reported-by: Kacper Kornet drae...@pld-linux.org
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
t/t3701-add-interactive.sh | 76 +-
1 file changed, 41 insertions(+), 35 deletions(-)
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
Kacper Kornet wrote:
Signed-off-by: Kacper Kornet drae...@pld-linux.org
Thanks.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Here's a style cleanup on top.
-- 8 --
Subject: reset test: modernize style
Avoid command substitution and pipes to ensure that the exit status
from each git
, since it should help
people to update the manual without fearing that new sections will
fail for people with ancient copies of git. For what it's worth,
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
Thomas Ackermann wrote:
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -312,10 +312,17 @@ referenced by a tag:
$ git checkout v2.6.17
- Note: moving to v2.6.17 which isn't a local branch
-
Thomas Ackermann wrote:
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3203,14 +3203,11 @@ To put the loose objects into a pack, just run git
repack:
$ git repack
[...]
-Total 6020, written 6020 (delta
Thomas Ackermann wrote:
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1784,17 +1784,6 @@ repository that you pulled from.
fast-forwards,fast-forward; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
-The
Junio C Hamano wrote:
Phil Hord phil.h...@gmail.com writes:
On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord ho...@cisco.com wrote:
When the pathspec given to grep includes a tree name, the full
name of matched files is assembled using colon as a separator.
If the pathspec includes a tree name, it
Thomas Ackermann wrote:
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -219,7 +219,7 @@ of development leading to that point.
The best way to see how this works is using the linkgit:gitk[1]
command; running gitk now on a Git repository and looking for merge
Thomas Ackermann wrote:
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1080,19 +1080,14 @@ produce no output at that point.
Modifying the index is easy:
-To update the index with the new contents of a modified file, use
+To add the contents of a new file
Thomas Ackermann wrote:
Describe the conflict resolution in terms of the
commands the user is supposed to use.
[...]
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1251,10 +1251,8 @@ Automatic merge failed; fix conflicts and then commit
the result.
Thomas Ackermann wrote:
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3992,16 +3992,16 @@ Merging multiple trees
Git helps you do a three-way merge, which you can expand to n-way by
repeating the merge procedure arbitrary times until you finally
-commit
Thomas Ackermann wrote:
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2131,8 +2131,6 @@ He uses two public branches:
- A test tree into which patches are initially placed so that they
can get some exposure when integrated with other ongoing development.
Jeff King wrote:
So we are necessarily reconstructing based on what we know of the
syntax. And I think that your rule is OK, because we know that refnames
cannot contain a colon.
What happens with expressions like HEAD^{/test:}?
Jonathan
--
To unsubscribe from this list: send the line
Hi,
Eric Sunshine wrote:
The short SHA-1 collision test requires carefully crafted commits in
order to ensure a collision at rebase time.
Yeah, this breaks the usual rule that tests should be independent
of hashing function. But it's the best we can do, I think.
[...]
---
Matthieu Moy wrote:
In most cases, feature foo does not just require that the feature
exists, but also changes the behavior to enable it.
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Eric Sunshine wrote:
Although undocumented, directory_exists_in_index_icase(dirname,len)
unconditionally assumes the presence of a '/' at dirname[len] (despite
being past the end-of-string). Callers are expected to respect
[...]
Fix this problem.
Hi,
Jeff King wrote:
---
I was tempted to not involve filter-branch in this commit at all, and
instead require the user to manually invoke
GIT_ALLOW_NULL_SHA1=1 git filter-branch ...
to perform such a filter. That would be slightly safer, but requires
some specialized knowledge from
Eric Sunshine wrote:
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1037,4 +1037,28 @@ test_expect_success 'rebase -i with --strategy and -X'
'
test $(cat file1) = Z
'
+test_expect_success 'short SHA-1 setup' '
+ test_when_finished git checkout
401 - 500 of 2895 matches
Mail list logo
