Each caller of index_name_exists() knows whether it is looking for a
directory or a file, and can avoid the unnecessary indirection of
index_name_exists() by instead calling index_dir_exists() or
index_file_exists() directly.
Invoking the appropriate search function explicitly will allow a
Depending upon the absence or presence of a trailing '/' on the incoming
pathname, index_name_exists() checks either if a file is present in the
index or if a directory is represented within the index. Each caller
explicitly chooses the mode of operation by adding or removing a
trailing '/' before
This series changes name-hash to stop storing the (redundant) trailing
slash with index_state.dir_hash entries. As an intentional side-effect,
the series fixes [1] in a cleaner way (suggested by Junio [2]) than
either [3] (680be044 in master) or [4].
Changes since v1 [5]:
* Add
directory_exists_in_index_icase() dangerously assumed that it could
access one character beyond the end of its directory argument, and that
that character would unconditionally be '/'. 2eac2a4c (ls-files -k: a
directory only can be killed if the index has a non-directory,
2013-08-15) added a
Matthieu Moy matthieu@grenoble-inp.fr writes:
Patrick Welche pr...@cam.ac.uk writes:
$ git diff
ESC[1mdiff --cc glib/gmain.cESC[m
ESC[1mindex 738e69c,5aaebd0..000ESC[m
ESC[1m--- a/glib/gmain.cESC[m
ESC[1m+++ b/glib/gmain.cESC[m
ESC[36m@@@ -4953,32 -4921,32 +4953,48 @@@ESC[m
Hi,
On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster toralf.foers...@gmx.de wrote:
I'm bisecting a linux kernel issue and want to ignore all commits just
touching something in ./drives/staging.
Currently the only way would be to specify all dir/subdir combination
under ./linux except that
Christian Couder christian.cou...@gmail.com writes:
In practice though, as git bisect is a kind of binary search, if what
you want to exclude is exclusively touched by half the commits, it
will only add one more bisection step if you don't exclude it.
Actually, I think the same remark would
2013/9/13 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com writes:
2013/9/13 Junio C Hamano gits...@pobox.com:
For systems that need POSIX escape hatch for Apollo Domain ;-), we
would need a bit more work. When both path1 and path2 begin with a
double-dash, we would
Tvangeste found that the relative_path function could not work
properly on Windows if in and prefix have DOS driver prefix
(such as C:/windows). And the relative_path function won't
work properly if either in or prefix is a UNC path (like
//host/share). ($gmane/234434)
E.g., When execute:
In test cases for relative_path, path with one leading character
(such as /a, /x) may be recogonized as a:/ or x:/ if there is
such DOS drive on MINGW platform. Use an umambigous leading path
/foo instead.
Also change two leading slashes (//) to three leading slashes (///),
otherwize it will be
hi
I like your crash curse http://git.or.cz/course/svn.html
(sorry for my bad English)
a little suggestion for revert/checkout
svn revert -R .--- git checkout id '*'
best regards
Michele Paoli
--
---
Dott. Michele Paoli
Innsbruck Medical
On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Christian Couder christian.cou...@gmail.com writes:
In practice though, as git bisect is a kind of binary search, if what
you want to exclude is exclusively touched by half the commits, it
will only add one
On Mon, Sep 16, 2013 at 01:18:48PM +0200, Matthieu Moy wrote:
Patrick Welche pr...@cam.ac.uk writes:
$ git diff
ESC[1mdiff --cc glib/gmain.cESC[m
ESC[1mindex 738e69c,5aaebd0..000ESC[m
ESC[1m--- a/glib/gmain.cESC[m
ESC[1m+++ b/glib/gmain.cESC[m
ESC[36m@@@ -4953,32 -4921,32
On Tue, Sep 17, 2013 at 09:15:43AM +0200, Matthieu Moy wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Patrick Welche pr...@cam.ac.uk writes:
$ git diff
ESC[1mdiff --cc glib/gmain.cESC[m
ESC[1mindex 738e69c,5aaebd0..000ESC[m
ESC[1m--- a/glib/gmain.cESC[m
ESC[1m+++
Patrick Welche pr...@cam.ac.uk writes:
Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by
default. If I take 1.8.3.4 and git -c color.ui=always log, I see
the same ESC codes = not a regression! I'll just have to sort my
box out if I want colour. (The only oddity is that git
On Tue, Sep 17, 2013 at 11:23:51AM +0200, Matthieu Moy wrote:
Patrick Welche pr...@cam.ac.uk writes:
Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by
default. If I take 1.8.3.4 and git -c color.ui=always log, I see
the same ESC codes = not a regression! I'll just have
Patrick Welche pr...@cam.ac.uk writes:
On Tue, Sep 17, 2013 at 11:23:51AM +0200, Matthieu Moy wrote:
Patrick Welche pr...@cam.ac.uk writes:
Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by
default. If I take 1.8.3.4 and git -c color.ui=always log, I see
the same ESC
On Tue, Sep 17, 2013 at 5:46 AM, Martin Gregory
martin.greg...@adelaideinterim.com.au wrote:
An additional note. I did
git ls-files -v | grep ^S
and I can see that the files that remain in the working version have the ^S
bit set.
So it does feel like a bug to me: why are files with ^S set
On Mon, Sep 16, 2013 at 8:20 PM, Martin Gregory
mart...@adelaideinterim.com.au wrote:
Hi,
Please see http://pastebin.com/zMXvvXuy
It shows that if the .git/info/sparsecheckout file is in windows format
(windows line ending) then it doesn't work.
And it does work for me with CRLF endings
On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder
christian.cou...@gmail.com wrote:
On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Christian Couder christian.cou...@gmail.com writes:
In practice though, as git bisect is a kind of binary search, if what
you
Separate the execution part to make future changes to the tests simpler.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
t/perf/perf-lib.sh | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh
index c61d535..95e483c
Currently there is no way to clean up the changes that have been made
with test_perf for the next run. Add a way to reset the repository to
the state before the test for testing commands that modify the git
repository, e.g. for perf testing git add.
Signed-off-by: Thomas Gummerer
It is Private
I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through the bank D.T.C Screen in my
office yesterday so I decided to use this very chance to know you. I believe we
should use every opportunity to know each other
Currently git-contacts only works if it is executed from the top level
of the git repository. Enable the execution in sub directories of that
repository.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
I have no experience in perl, so there may be nicer implementations. It works
when
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Makefile | 5 -
gitconfig | 5 +
2 files changed, 9 insertions(+), 1 deletion(-)
create mode 100644 gitconfig
diff --git
So that we can specify general modes of operation, specifically, add the
'next' mode, which makes Git pre v2.0 behave as Git v2.0.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/add.c | 3 +++
cache.h | 6 ++
config.c | 13 +
environment.c |
Sebastian Schuberth sschube...@gmail.com writes:
I think this is less favorable compared to my last proposed solution.
That is only needed if you insist to use C preprocessor that does
not understand include_next. That choice is a platform specific
decision (even if you want to use such a
Torsten Bögershausen tbo...@web.de writes:
Yes,
there is a directoctory structure in / like this:
/usr
/bin
/lib
Then we have the drive letters mapped to single letters:
/c/Documents and Settings
/c/temp
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Jiang Xin worldhello@gmail.com writes:
diff --git a/compat/mingw.h b/compat/mingw.h
index bd0a88b..06e9f49 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -311,6 +311,15 @@ int winansi_fprintf(FILE *stream, const char *format,
...) __attribute__((format
#define
Michael S. Tsirkin m...@redhat.com writes:
Actually, after I've looked at the code,
diffcore_order is already already called for patch-id.
That was a band-aid for an ill-thought-out orderfile misfeature to
hide the breakage. You somehow make sure that you pass the same
orderfile to diff
On 09/17/2013 09:26 AM, Christian Couder wrote:
Hi,
On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster toralf.foers...@gmx.de
wrote:
I'm bisecting a linux kernel issue and want to ignore all commits just
touching something in ./drives/staging.
Currently the only way would be to specify all
Ramkumar Ramachandra artag...@gmail.com writes:
Is $GIT_OBJECT_DIRECTORY a standard variable, or should it be
$GIT_DIR/objects?
man git ;-) It has been there since early May 2005
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Eric Sunshine sunsh...@sunshineco.com writes:
* Split v1 patch 1 into v2 patches 1 2 to ease review. (This is
possible now that index_name_exists() retains its original behavior.)
It really shows in [PATCH 2/4] that illustrates which callers were
depending on the old calling convention; I
On Tue, Sep 17, 2013 at 8:50 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
Currently git-contacts only works if it is executed from the top level
of the git repository. Enable the execution in sub directories of that
repository.
Thanks. This was on my to-do list but fell off my radar when I
Michael S. Tsirkin m...@redhat.com writes:
So might it not be useful to tweak patch id to
sort the diff, making it a bit more stable?
That is one thing that needs to be done, I think. But it would be
unfortunate if we have to do that unconditionally, though, as we may
be buffering many
On Tue, Sep 17, 2013 at 09:26:13AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
Actually, after I've looked at the code,
diffcore_order is already already called for patch-id.
That was a band-aid for an ill-thought-out orderfile misfeature to
hide the
Your e-mail has won you ￡1,000,000.00 from BBC XMAS PROMO
1, Name
2, Country
3, Mobile No
4, Occupation
Send Response to ( eruraf...@56788.com )
Prof. Peter
--==Mailed via NDMCTSGH Webmail==--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Duy Nguyen pclo...@gmail.com writes:
On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder
christian.cou...@gmail.com wrote:
On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Christian Couder christian.cou...@gmail.com writes:
In practice though, as git bisect
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
So might it not be useful to tweak patch id to
sort the diff, making it a bit more stable?
That is one thing that needs to be done, I think. But it would be
unfortunate if we have
Burton, Ross ross.bur...@intel.com writes:
Why does git-bisect need to be ran from the top level of the working
tree? It sources git-sh-setup.sh which sets GIT_DIR, which
git-bisect.sh then appears to consistently use. Is there a reason for
needing to be at the top-level, or is this an old
Junio C Hamano gits...@pobox.com napisał:
Yeah, it is easy to say that
git log -- A ':(exclude)A/B' A/B/C
has two positive (A, A/B/C) and one negative (A/B), and then the
most specific one A/B/C matches a path A/B/C/D and hence A/B/C/D is
included.
But to actually _design_ it, there are
Thomas Gummerer t.gumme...@gmail.com writes:
+For performance tests that need cleaning up after them that should not
+be timed, use
+
+ test_perf_cleanup 'descriptive string' '
+ command1
+ command2
+ ' '
+ cleanupcommand1
+
I'm trying out a rather large subversion import, and am trying to
figure out if there is a way to delete branches during a fast-import.
Right now I can think of only 2 ways to handle this:
1) End the import, do a git branch -D and then resume the import.
2) Scan the entire repository history,
On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote:
Burton, Ross ross.bur...@intel.com writes:
Why does git-bisect need to be ran from the top level of the working
tree? It sources git-sh-setup.sh which sets GIT_DIR, which
git-bisect.sh then appears to consistently use. Is
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
So might it not be useful to tweak patch id to
sort the diff, making it a bit more stable?
That is one thing that needs to be done, I
Stefan Beller stefanbel...@googlemail.com writes:
+ struct option builtin_repack_options[] = {
+ OPT_BIT('a', NULL, pack_everything,
+ N_(pack everything in a single pack),
ALL_INTO_ONE),
+ OPT_BIT('A', NULL, pack_everything,
+
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
What about simply iterating over options in order in which they
are specified and the last option that matches specifies the
result?
But isn't it very inconsistent from the way normal pathspec works?
git log -- A B and git log -- B A
Hello,
after these commands:
$ git init
$ mkdir subdir
$ echo a subdir/a
$ git add subdir/a
$ git commit -m a
$ echo more a subdir/a
$ echo b subdir/b
$ git add subdir/*
$ git commit -m b
$ git checkout HEAD^ --
On 17 September 2013 18:27, Junio C Hamano gits...@pobox.com wrote:
Burton, Ross ross.bur...@intel.com writes:
Why does git-bisect need to be ran from the top level of the working
tree? It sources git-sh-setup.sh which sets GIT_DIR, which
git-bisect.sh then appears to consistently use. Is
On Tue, Sep 17, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote:
Keeping the ugliness to deal with the platform issue (i.e. broken
string.h) in one place (e.g. compat/mingw) is far more preferrable
than having a similar ugliness in git-compat-util.h for people on
all other platforms
Lukas Fleischer g...@cryptocrack.de writes:
Imagine if you start from a subdirectory foo/ but the directory did
not exist in the older part of the history of the project. When
bisect needs to check out a revision that was older than the first
revision that introduced that subdirectory, what
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
So might it not be useful to tweak patch id to
sort the diff, making
On Tue, Sep 17, 2013 at 9:04 PM, Junio C Hamano gits...@pobox.com wrote:
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
What about simply iterating over options in order in which they
are specified and the last option that matches specifies the
result?
But isn't it very
Ooops. It seems that each time somebody says these two words together,
people hate him, and he is scorned by friends and family.
However,
- gitolite implement it (but gitolite is not git).
- In the documentation, each time the need is evocated, it is replace
by do communication, don't use git for
Am 17.09.2013 10:24, schrieb Jiang Xin:
I have checked the behavior of UNC path on Windows (msysGit):
* I can cd to a UNC path:
cd //server1/share1/path
* can cd to other share:
cd ../../share2/path
* and can cd to other server's share:
cd ../../../server2/share/path
Jason Miller wrote:
I'm trying out a rather large subversion import, and am trying to
figure out if there is a way to delete branches during a fast-import.
Right now I can think of only 2 ways to handle this:
1) End the import, do a git branch -D and then resume the import.
2) Scan the
Uwe Kleine-König u.kleine-koe...@pengutronix.de writes:
after these commands:
$ git init
$ mkdir subdir
$ echo a subdir/a
$ git add subdir/a
$ git commit -m a
$ echo more a subdir/a
$ echo b subdir/b
$ git add subdir/*
$ git
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
I could argue that the above intended behaviour is suboptimal and it
should have been the resulting paths in the index and the work tree
that match the given pathspec must be identical to that of the
tree-ish. In the resulting
On Tue, Sep 17, 2013 at 09:06:59PM +0200, Uwe Kleine-König wrote:
$ git checkout HEAD^ -- subdir
I'd expect that subdir/b is removed from the index as this file didn't
exist in HEAD^ but git-status only reports:
I'm not sure if this is intentional or not. The definition of git
On 09/15/2013 05:31 PM, Stefan Beller wrote:
Rene, thank you very much for the review!
the parameter hex contains the pack- already.
The remove_redundant_pack function is called in a loop iterating over
elements of existing_packs, which is filled in get_non_kept_pack_filenames,
which
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
Thinking about it some more, it's a best effort thing anyway,
correct?
So how about, instead of doing a hash over the whole input,
we hash each chunk and XOR them together?
This way it will be stable against chunk
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
So might it not be useful to tweak patch id to
sort the diff, making
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
I could argue that the above intended behaviour is suboptimal and it
should have been the resulting paths in the index and the work tree
that match the given pathspec must be identical to that of
On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
I could argue that the above intended behaviour is suboptimal and it
should have been the resulting paths in the index and the
Stefan Beller stefanbel...@googlemail.com writes:
On 09/17/2013 08:17 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
+ struct option builtin_repack_options[] = {
+ OPT_BIT('a', NULL, pack_everything,
+ N_(pack everything in
On Tue, Sep 17, 2013 at 11:14:01PM +0300, Michael S. Tsirkin wrote:
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote:
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
Thinking about it some more, it's a best effort thing anyway,
correct?
So how about, instead of doing a hash over the whole input,
we hash each chunk
On Wed, Sep 18, 2013 at 12:03:25AM +0300, Michael S. Tsirkin wrote:
It may be esoteric enough not to worry about, though. By far the most
common use of patch-ids is going to be in a single rev-list
--cherry-pick situation where you are trying to omit commits during
a rebase.
I am
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
A problem with both schemes, though, is that they are not
backwards-compatible with existing git-patch-id implementations.
Could you clarify?
We never send patch IDs on the wire - how isn't this compatible?
I meant that
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
I could argue that the above intended behaviour is suboptimal and it
should have been the
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote:
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
Thinking about it some more, it's a best effort thing anyway,
correct?
So how
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
Ignoring (possible) inconsistency thing, I think they are easy to
understand and use.
Probably you are right (in the sense that I do not offhand think of
a confusing and ambiguous set of positive and negative pathspecs;
others may find
On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
A problem with both schemes, though, is that they are not
backwards-compatible with existing git-patch-id implementations.
Could you clarify?
We never send
On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote:
Hrm. Probably not. It is almost a one-way merge going to the named tree
(but limited by the pathspec), except that I think the current
git-checkout code may provide some safety checks related to where we are
coming from
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:
Ooops. It seems that each time somebody says these two words together,
people hate him, and he is scorned by friends and family.
And strangers on mailing lists. :)
However,
- gitolite implement it (but gitolite is not
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:
Ooops. It seems that each time somebody says these two words together,
people hate him, and he is scorned by friends and family.
For the moment, i want a first feedback, an intermediate between
locking is bad and ok, but
Sebastian Schuberth sschube...@gmail.com writes:
On Tue, Sep 17, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote:
Keeping the ugliness to deal with the platform issue (i.e. broken
string.h) in one place (e.g. compat/mingw) is far more preferrable
than having a similar ugliness in
Jeff King p...@peff.net writes:
On Tue, Sep 17, 2013 at 03:00:41PM -0700, Junio C Hamano wrote:
So given that, is it fair to say that a one-way go here merge, limited
by pathspec, is the closest equivalent?
Sorry, but it is unclear to me what you mean by one-way go here
merge. Do you
Hi Duy,
Thanks for taking a look.
So it does feel like a bug to me: why are files with ^S set remaining in
the
working version after
git read-tree -mu HEAD
?
I don't know. Maybe the bits are set, but then the remove operation
fails (silently). I tried to reproduce on
Jeff King p...@peff.net writes:
I am mostly thinking of the problems we had with the kup tool, which
expected stability across diffs that would be signed by both kernel.org.
But as far as I know, they do not use patch-id. More details in case you
are curious (including me arguing that we
Hi Duy,
Thanks again for taking a look at these two reports.
And it does work for me with CRLF endings (again tested on Linux).
Yes, will do.
I will try, myself, on Linux, as well. It seems quite conceivable its the
sort of thing that only happens under Windows.
Regards,
Martin
--
To
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5601-clone.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0629149..ccda6df 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -285,4 +285,15 @@ test_expect_success
This reworks the old idea from 2008 ($gmane/102039) to teach
upload-pack to say where symbolic refs are pointing at in the
initial ref advertisement as a new capability sym, and allow
git clone to take advantage of that knowledge when deciding what
branch to point at with the HEAD of the newly
One long-standing flaw in the pack transfer protocol was that there
was no way to tell the other end which branch HEAD points at.
With a new sym capability (e.g. sym=HEAD:refs/heads/master; can
be repeated more than once to represent symbolic refs other than
HEAD, such as
With the same mechanism as used to tell where HEAD points at to
the other end, we can tell the target of other symbolic refs as
well.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
upload-pack.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/upload-pack.c b/upload-pack.c
index
Unlike other git commands which work correctly at the top-level or in a
subdirectory, git-contacts fails when invoked in a subdirectory. This is
because it invokes git-blame with pathnames relative to the top-level,
but git-blame interprets the pathnames as relative to the current
directory. Fix
With the same mechanism as used to tell where HEAD points at to
the other end, we can tell the target of other symbolic refs as
well.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
upload-pack.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/upload-pack.c b/upload-pack.c
index
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5601-clone.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0629149..ccda6df 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -285,4 +285,15 @@ test_expect_success
This reworks the old idea from 2008 ($gmane/102039) to teach
upload-pack to say where symbolic refs are pointing at in the
initial ref advertisement as a new capability symref, and allows
git clone to take advantage of that knowledge when deciding what
branch to point at with the HEAD of the newly
By doing this, clients of upload-pack can now reliably tell what ref
a symbolic ref points at; the updated test in t5505 used to expect
failure due to the ambiguity and made sure we give diagnostics, but
we no longer need to be so pessimistic. Make sure we correctly learn
which branch HEAD points
One long-standing flaw in the pack transfer protocol was that there
was no way to tell the other end which branch HEAD points at.
With a capability symref=HEAD:refs/heads/master, let the sender to
tell the receiver what symbolic ref points at what ref.
This capability can be repeated more than
The callee does not use cb_data, and the caller is an intermediate
function in a callchain that later wants to use the cb_data for its
own use. Clarify the code by breaking the dataflow explicitly by
not passing cb_data down to mark_our_ref().
Signed-off-by: Junio C Hamano gits...@pobox.com
---
When two or more branches point at the same commit and HEAD is
pointing at one of them, without the symref extension, there is no
way to remotely tell which one of these branches HEAD points at.
The test in question attempts to make sure that this situation is
diagnosed and results in a failure.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
cache.h | 1 -
connect.c | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 85b544f..2c853ba 100644
--- a/cache.h
+++ b/cache.h
@@ -1098,7 +1098,6 @@ extern struct ref **get_remote_heads(int in,
94 matches
Mail list logo
