On Sun, Sep 9, 2012 at 9:24 PM, Junio C Hamano wrote:
> Ralf Thielow writes:
>
>> If "core.ignorecase" is true, "git blame" fails
>> when the given path differs to the real path in case
>> sensitivity.
>
> It is rather hard to respond to this request for comment because you
> are describing the b
Michael Haggerty writes:
> ... Consider something like
>
> struct string_list *split_file_into_words(FILE *f)
> {
> char buf[1024];
> struct string_list *list = new string list;
> list->strdup_strings = 1;
> while (not EOF) {
> read_line_into_b
On 09/09/2012 11:35 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Split a string into a string_list on a separator character.
>>
>> This is similar to the strbuf_split_*() functions except that it works
>> with the more powerful string_list interface. If strdup_strings is
>> false, i
Pete Wyckoff writes:
> Option "--silent", "--quiet" or "-s" to make prevents
> echoing of commands as they are executed. However, there
> are some explicit "echo" commands in the Makefile and in
> the two GIT-VERSION-GEN scripts that always echo.
"make -s clean"?
I am not very enthused, especi
Junio C Hamano writes:
> Angelo Borsotti writes:
>
>> It makes quite clear that the command accepts wildcards
>> (not expanded by the shell), which was is not clear in the current
>> man page (although one could imagine that could also be a
>> wildcard).
>>
>> P.S. In the man page there is also
From: "Junio C Hamano"
Matthieu Moy writes:
Junio C Hamano writes:
"Philip Oakley" writes:
Having said that, it would therefore be better to point folk at
gitcli
in a few more places, not just the 'see also' line at the very end
of
the general 'git' page, and buried within rev-parse.
Option "--silent", "--quiet" or "-s" to make prevents
echoing of commands as they are executed. However, there
are some explicit "echo" commands in the Makefile and in
the two GIT-VERSION-GEN scripts that always echo.
Quiet the explicit "echo"s in Makefile when MAKEFLAG "s"
is set. Pass this inf
Make git-grep optionally omit the parts of the line before and after the
match.
Signed-off-by: Marcus Karlsson
---
Documentation/git-grep.txt | 8 +++-
builtin/grep.c | 2 ++
grep.c | 7 +--
grep.h | 1 +
4 files changed, 15 insertions(
This allows specifying what to do when a conflict
happens when applying a commit to p4, automating the
interactive prompt.
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 11
git-p4.py | 36 +
t/t9815-git-p4-submit-fail.sh | 63
This option can be used to prepare the client workspace for
submission, only. It does not invoke the final "p4 submit".
A message describes how to proceed, either submitting the
changes or reverting.
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 7 +++
git-p4.py
A new option, "git p4 submit --dry-run" can be used to verify
what commits and labels would be moved into p4.
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 4
git-p4.py| 43 ++-
t/t9807-git-p4-submit.sh | 41 +
The short form "-v" is common in many git commands as an
alias for "--verbose".
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 2 +-
git-p4.py| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
ind
The user can decide not to continue with a submission,
by not saving the p4 submit template, then answering "no" to
the "Submit anyway?" prompt. In this case, be sure to
return the p4 client to its initial state.
Deleted files were not reverted; fix this and test all cases.
Signed-off-by: Pete W
Put all items in order as they appear, and add comments.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 0481f43..ea14c1f 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1202,6 +12
Test a variety of cases where a patch failed to apply to
p4 and had to be cleaned up.
If the patch failed to apply cleanly, do not try to remove
to-be-added files, as they have not really been added yet.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 2 -
t/t9815-git-p4-submi
When editing the submit template, if no change was made to it,
git p4 offers a prompt "Submit anyway?". Answering "no" cancels
the submit.
Previously, a "no" answer behaves like a "[s]kip" answer to the
failed-patch prompt, in that it proceeded to try to apply the
rest of the commits. Instead, p
When applying a commit to the p4 workspace fails, a prompt
asks what to do next. This belongs up in run() instead
of in applyCommit(), where run() can notice, for instance,
that the prompt is unnecessary because this is the last commit.
Offer two options about how to continue at conflict: [s]kip
When a patch failed to apply, these interactive options offered
to:
1) apply the patch anyway, leaving reject (.rej) files around, or,
2) write the patch to a file (patch.txt)
In both cases it suggested to invoke "git p4 submit --continue",
an unimplemented option.
While manually fixing
If a commit fails to apply cleanly to the p4 tree, an interactive
prompt asks what to do next. In all cases (skip, apply, write),
the behavior after the prompt had a few problems.
Change it so that it does not claim erroneously that all commits
were applied. Instead list the set of the patches u
Signed-off-by: Pete Wyckoff
---
t/lib-git-p4.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 2d753ab..482eeac 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -26,9 +26,10 @@ testid=${this_test#t}
git_p4_test_start=9800
Changes from v1, due to review from Luke and Hannes:
* Drop the patch to suppress of p4d log messages, it is
sometimes useful to watch.
* Fix extra line before shebang in t9815. (Thanks Hannes.)
* Use "skip", not "continue" in the prompt about what to
do next, just like
Junio C Hamano writes:
> If we were to do anything, I would think the most sane thing to do
> is a smaller patch to fix fake_working_tree_commit() where it calls
> lstat() and _should_ die with "Cannot lstat MakeFILE" on a sane
> filesystem. It does not currently make sure the path exists in the
Ralf Thielow writes:
> If "core.ignorecase" is true, "git blame" fails
> when the given path differs to the real path in case
> sensitivity.
It is rather hard to respond to this request for comment because you
are describing the behaviour you perceive as a problem only fuzzily
(i.e. "fails"---wh
Am 09.09.2012 19:01, schrieb Ralf Thielow:
> If "core.ignorecase" is true, "git blame" fails
> when the given path differs to the real path in case
> sensitivity.
...
> + dir = opendir(res.buf);
...
> + struct dirent *ent = readdir(dir
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> "Philip Oakley" writes:
>>
>>> Having said that, it would therefore be better to point folk at gitcli
>>> in a few more places, not just the 'see also' line at the very end of
>>> the general 'git' page, and buried within rev-parse.
>>
>> Didn'
Jeff King writes:
> On Sun, Sep 09, 2012 at 03:20:18AM -0700, Junio C Hamano wrote:
>
>> Michael Haggerty writes:
>>
>> > This patch series depends on the "Add some string_list-related
>> > functions" series that I just submitted.
>>
>> Makes sense. The only worry (without reading the series
If "core.ignorecase" is true, "git blame" fails
when the given path differs to the real path in case
sensitivity.
Signed-off-by: Ralf Thielow
---
.gitignore | 1 +
Makefile | 3 +++
builtin/blame.c| 58 ++
test-p
Only the first half of the test works only on POSIX, the second half
passes on Windows as well.
A later test "real path removes other extra slashes" looks very similar,
but it does not make sense to split it in the same way: When two slashes
are prepended in front of an absolute DOS-style path on
Hi,
This is probably the wrong way to do this, and I'm sorry if I end up
wasting someone's time. That said, here goes
While idly browsing through the git source (as you do on a sunny Sunday
afternoon), I spotted the following code (that appears to be wrong) in
the file https://github.co
- Original Message -
> From: "Junio C Hamano"
> Sent: Sunday, September 9, 2012 12:40:37 AM
> Subject: [PATCH 0/2] Teaching -Xours/-Xtheirs to binary ll-merge driver
>
> The part that grants Stephen's wish is unchanged from the earlier
> "perhaps like this" patch, but this time with a bit
"Maris, Rob" writes:
> Normally, when there are modifications in the working tree not yet added
> resp. committed, git will refuse to change to another branch.
Only if switching the branch requires touching the modified files.
> Actually, the modified
> status of git related to both branches af
Junio C Hamano writes:
> "Philip Oakley" writes:
>
>> Having said that, it would therefore be better to point folk at gitcli
>> in a few more places, not just the 'see also' line at the very end of
>> the general 'git' page, and buried within rev-parse.
>
> Didn't we update the very early part o
Normally, when there are modifications in the working tree not yet added
resp. committed, git will refuse to change to another branch.
However, when I create a new branch on the fly, using git checkout -b
, there is no complaint appearing. After doing so, I executed a
git reset --hard in once
On Sun, Sep 09, 2012 at 03:20:18AM -0700, Junio C Hamano wrote:
> Michael Haggerty writes:
>
> > This patch series depends on the "Add some string_list-related
> > functions" series that I just submitted.
>
> Makes sense. The only worry (without reading the series first) I
> have is that the u
┌─┬─┬─┬─┬─┬─┬─┬─┐
│ ┆ ┆联┆Ｑ┆手┆较┆优┆ │
│ ┆ ┆系┆Ｑ┆机┆低┆惠┆ │
│ ┆ ┆人┆：┆１┆，┆开┆ │
│ ┆ ┆：┆１┆３┆先┆具┆ │
│ ┆ ┆ ┆２┆６┆验┆企┆ │
│ ┆ ┆ ┆６┆３┆证┆业┆ │
│ ┆ ┆李┆０┆１┆后┆正┆ │
│ ┆ ┆︵┆４┆４┆付┆规┆ │
│ ┆ ┆先┆８┆５┆款┆发┆ │
│ ┆ ┆生┆５┆６┆！┆票┆ │
│ ┆ ┆︶┆０┆０┆ ┆，┆ │
│ ┆ ┆ ┆３┆０┆ ┆收┆ │
│ ┆ ┆ ┆３┆９┆ ┆费┆ │
└─┴─┴─┴─┴─┴─┴─┴─┘
N�r��yb�X��ǧv�^�){.n
Michael Haggerty writes:
> This patch series depends on the "Add some string_list-related
> functions" series that I just submitted.
Makes sense. The only worry (without reading the series first) I
have is that the use of string list may make the responsiblity of
sorting the list fuzzier. I am
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
> Documentation/technical/api-string-list.txt | 8
> string-list.c | 20 +++
> string-list.h | 8
> t/t0063-string-list.sh
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
> Documentation/technical/api-string-list.txt | 4
> string-list.c | 17 +
> string-list.h | 5 +
> 3 files changed, 26 insertions(+)
>
> diff
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
> Documentation/technical/api-string-list.txt | 8
> string-list.c | 17 +
> string-list.h | 9 +
> 3 files changed, 34 insertions(+)
>
Michael Haggerty writes:
> Split a string into a string_list on a separator character.
>
> This is similar to the strbuf_split_*() functions except that it works
> with the more powerful string_list interface. If strdup_strings is
> false, it reuses the memory from the input string (thereby need
David Chanters writes:
> 2. At this point I scan the two branches looking for a point to
> graft; I might have done this already in the past, but the point is
> since grafting is a local operation and I am not working in that
> repository, I might need to do it again anyway -- that graft
> repre
Hi,
On 9 September 2012 09:36, Andreas Schwab wrote:
> Add "bsd" as a remote in "portable" and cherry-pick each commit in
> "bsd".
I am already kind of doing this at the moment. Hence:
1. In portable, I have:
% git remote add bsd /path/to/bsd/repo
% git fetch bsd
2. At this point I scan th
Add "bsd" as a remote in "portable" and cherry-pick each commit in
"bsd".
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsu
Hi all,
I'm wondering how best to go about this problem. I've got two
separate git repositories -- one is a portable version which I'll call
"portable", the other is part of a BSD project, which I'll call "bsd".
Both repositories have the same set of *conceptual* files in them,
it's just that th
44 matches
Mail list logo
