This patch series depends on the Add some string_list-related
functions series that I just submitted.
This series is a significant rewrite of v2 based on the realization
that the nr_heads,heads pair that is passed around in these
functions is better expressed as a string_list. I hope you will
If git fetch-pack is called with reference names that do not exist
on the remote, then it should emit an error message
error: no such remote ref refs/heads/xyzzy
This is currently broken if *only* missing references are passed to
git fetch-pack.
Signed-off-by: Michael Haggerty
Document some bugs in git fetch-pack:
1. If git fetch-pack is called with --all, --depth, and an
explicit existing non-tag reference to fetch, then it falsely reports
that the reference was not found, even though it was fetched
correctly.
2. If git fetch-pack is called with --all, --depth, and
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 8
fetch-pack.h | 12 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index fdda36f..30990c0 100644
---
Once a match has been found at sought_pos, the entry is zeroed and no
future attempts will match that entry. So increment sought_pos to
avoid checking against the zeroed-out entry during the next iteration.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 2 +-
1
Avoid confusion with the non-static function of the same name from
fetch-pack.h.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
http-walker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/http-walker.c b/http-walker.c
index 51a906e..1516c5e 100644
---
Instead of juggling nr_heads,heads (sometimes called
nr_match,match), pass around the list of references to be sought in
a single string_list variable called sought. Future commits will
make more use of string_list functionality.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Remove any references that are available from the remote from the
sought list (rather than overwriting their names with NUL characters,
as previously). Mark matching entries by writing a non-NULL pointer
to string_list_item::util during the iteration, then use
filter_string_list() later to filter
Instead of temporarily storing matched refs to temporary array
return_refs, simply append them to newlist as we go. This changes
the order of references in newlist to strictly sorted if --all and
--depth and named references are all specified, but that usage is
broken anyway (see the last two
This fixes a test in t5500.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 2 +-
t/t5500-fetch-pack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index fb2a423..3d388b5 100644
---
This simplifies the logic without changing the behavior.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 056ccb8..fb2a423 100644
---
Set the final value at initialization rather than initializing it then
sometimes changing it.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/builtin/fetch-pack.c
It used to be that if --all, --depth, and also explicit references
were sought, then the explicit references were not handled correctly
in filter_refs() because the --all --depth code took precedence over
the explicit reference handling, and the explicit references were
never noted as having been
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 the
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 unsubscribe
Hi,
On 9 September 2012 09:36, Andreas Schwab sch...@linux-m68k.org 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
David Chanters david.chant...@googlemail.com 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
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-string-list.txt | 8
string-list.c | 17 +
string-list.h | 9 +
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-string-list.txt | 4
string-list.c | 17 +
string-list.h | 5 +
3 files
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-string-list.txt | 8
string-list.c | 20 +++
string-list.h | 8
Michael Haggerty mhag...@alum.mit.edu 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
┌─┬─┬─┬─┬─┬─┬─┬─┐
│ ┆ ┆联┆Ｑ┆手┆较┆优┆ │
│ ┆ ┆系┆Ｑ┆机┆低┆惠┆ │
│ ┆ ┆人┆：┆１┆，┆开┆ │
│ ┆ ┆：┆１┆３┆先┆具┆ │
│ ┆ ┆ ┆２┆６┆验┆企┆ │
│ ┆ ┆ ┆６┆３┆证┆业┆ │
│ ┆ ┆李┆０┆１┆后┆正┆ │
│ ┆ ┆︵┆４┆４┆付┆规┆ │
│ ┆ ┆先┆８┆５┆款┆发┆ │
│ ┆ ┆生┆５┆６┆！┆票┆ │
│ ┆ ┆︶┆０┆０┆ ┆，┆ │
│ ┆ ┆ ┆３┆０┆ ┆收┆ │
│ ┆ ┆ ┆３┆９┆ ┆费┆ │
└─┴─┴─┴─┴─┴─┴─┴─┘
On Sun, Sep 09, 2012 at 03:20:18AM -0700, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
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
branch, there is no complaint appearing. After doing so, I executed a
git reset --hard
Junio C Hamano gits...@pobox.com writes:
Philip Oakley philipoak...@iee.org 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
Maris, Rob maris@ingenieur.de 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
- Original Message -
From: Junio C Hamano gits...@pobox.com
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
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
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 ralf.thie...@gmail.com
---
.gitignore | 1 +
Makefile | 3 +++
builtin/blame.c| 58
Jeff King p...@peff.net writes:
On Sun, Sep 09, 2012 at 03:20:18AM -0700, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
This patch series depends on the Add some string_list-related
functions series that I just submitted.
Makes sense. The only worry (without
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Philip Oakley philipoak...@iee.org 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
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);
...
Ralf Thielow ralf.thie...@gmail.com 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
Junio C Hamano gits...@pobox.com 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
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
Signed-off-by: Pete Wyckoff p...@padd.com
---
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}
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
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
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 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, put
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 p...@padd.com
---
git-p4.py | 2 -
Put all items in order as they appear, and add comments.
Signed-off-by: Pete Wyckoff p...@padd.com
---
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
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
The short form -v is common in many git commands as an
alias for --verbose.
Signed-off-by: Pete Wyckoff p...@padd.com
---
Documentation/git-p4.txt | 2 +-
git-p4.py| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-p4.txt
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 p...@padd.com
---
Documentation/git-p4.txt | 4
git-p4.py| 43 ++-
t/t9807-git-p4-submit.sh | 41
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 p...@padd.com
---
Documentation/git-p4.txt | 7 +++
git-p4.py
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 p...@padd.com
---
Documentation/git-p4.txt | 11
git-p4.py | 36 +
Make git-grep optionally omit the parts of the line before and after the
match.
Signed-off-by: Marcus Karlsson m...@acc.umu.se
---
Documentation/git-grep.txt | 8 +++-
builtin/grep.c | 2 ++
grep.c | 7 +--
grep.h | 1 +
4 files
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 echos in Makefile when MAKEFLAG s
is set. Pass this information
From: Junio C Hamano gits...@pobox.com
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Philip Oakley philipoak...@iee.org writes:
Having said that, it would therefore be better to point folk at
gitcli
in a few more places, not just the 'see also'
Junio C Hamano gits...@pobox.com writes:
Angelo Borsotti angelo.borso...@gmail.com 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 path could also be a
wildcard).
Pete Wyckoff p...@padd.com 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,
On 09/09/2012 11:35 AM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu 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) {
On Sun, Sep 9, 2012 at 9:24 PM, Junio C Hamano gits...@pobox.com wrote:
Ralf Thielow ralf.thie...@gmail.com 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
56 matches
Mail list logo
