On Wed, Aug 20, 2014 at 12:06 AM, Junio C Hamano wrote:
> The basic flow based on this mechanism goes like this:
>
> 1. You push out your work with "git push -s".
>
> 2. The sending side learns where the remote refs are as usual,
> together with what protocol extension the receiving end
>
No code == no substance might be a stretch, but definitely fair enough.
I thought the idea was clear enough, but I can flesh it out if
desired. The particular advantage I saw in it is that it would reuse
the existing object infrastructure, and extend to branches the
first-class treatment that [si
On Tue, Aug 19, 2014 at 7:54 PM, Junio C Hamano wrote:
> Sorry, but I cannot answer, as the only thing that I recall when
> I hear "branch object" was that I heard the phrase used but
> without much substance.
Just to avoid unnecessary misunderstanding, by the above, especially
the "without much
On Tue, Aug 19, 2014 at 10:14:30PM -0400, Jeff King wrote:
> diff --git a/t/t4038-diff-combined.sh b/t/t4038-diff-combined.sh
> index 1019d7b..71a664d 100755
> --- a/t/t4038-diff-combined.sh
> +++ b/t/t4038-diff-combined.sh
> @@ -401,4 +401,38 @@ test_expect_success 'combine diff missing delete bu
Job Offer,$3,000 Monthly salary,For inquires & more info, contact us via
email:nuamironsteelco...@outlook.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
Sorry, but I cannot answer, as the only thing that I recall when
I hear "branch object" was that I heard the phrase used but
without much substance.
I do not think I saw a clear explanation on what it is, how it is
represented, how it is presented to the end user, how it is
propagated across repos
On Tue, Aug 19, 2014 at 03:06:24PM -0700, Junio C Hamano wrote:
> While signed tags and commits assert that the objects thusly signed
> came from you, who signed these objects, there is not a good way to
> assert that you wanted to have a particular object at the tip of a
> particular branch. My s
On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano wrote:
>
> If the server's GPG keychain and pre-receive hook are properly set
> up, a "git push --signed" over an unauthenticated and unencrypted
> communication channel (aka "git daemon") can be made as secure as,
> and even more secure than, the au
When we do a combined diff, we individually diff against
each parent, and then use intersect_paths to do a parallel
walk through the sorted results and come up with a final
list of interesting paths.
The sort order here is that returned by the diffs, which
means it is in git's tree-order which sor
On Tue, Aug 19, 2014 at 03:06:09PM -0700, Junio C Hamano wrote:
> While signed tags and commits assert that the objects thusly signed
> came from you, who signed these objects, there is not a good way to
> assert that you wanted to have a particular object at the tip of a
> particular branch. My s
I don't think anybody can come up with a good auditing and recording
scheme without sufficient experience. Because I want to avoid whatever
random scheme we happen to implement first in git-core, even if it is
way suboptimal, ends up as the de-facto standard, I deliberately stayed
away from adding
On Wed, Aug 20, 2014 at 5:06 AM, Junio C Hamano wrote:
> While signed tags and commits assert that the objects thusly signed
> came from you, who signed these objects, there is not a good way to
> assert that you wanted to have a particular object at the tip of a
> particular branch. My signing v
Junio C Hamano writes:
> This piece of code reads object names of shallow boundaries,
> not old_sha1[].
>
> Signed-off-by: Junio C Hamano
> ---
I should double the subject line and say "do not reuse ... for other
things".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
Junio C Hamano writes:
> Ideally, we should have also allowed the first "shallow" to carry
> the feature request trailer, but that is water under the bridge
> now. This makes the next step to factor out the queuing of commands
> easier to review.
>
> Signed-off-by: Junio C Hamano
> ---
> ...
>
Ronnie Sahlberg writes:
> List, please see here an overview and ordering of the ref transaction
> patch series.
> These series build on each other and needs to be applied in the order
> listed below.
>
> This is an update.
>
> rs/ref-transaction-0
> ---
> Early part of
Johannes Sixt writes:
> Am 19.08.2014 19:15, schrieb Robin Rosenberg:
>> Using the original filename suffix for the temporary input files to
>> the merge tool confuses IDEs like Eclipse. This patch introduces
>> a configurtion option, mergetool.tmpsuffix, which get appended to
>> the temporary fi
We use it to make sure that the feature request is sent only once on
the very first request packet (ignoring the "shallow " line, which
was an unfortunate mistake we cannot retroactively fix with existing
receive-pack already deployed in the field) and we set it to "true"
with cmds_sent++, not beca
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it d
We would want to update the interim protocol so that we do not send
the usual update commands when the push certificate feature is in
use, as the same information is in the certificate. Once that
happens, the push-cert packet may become the only protocol command,
but then there is no packet to put
Our signed-tag objects set the standard format used by Git to store
GPG-signed payload (i.e. the payload followed by its detached
signature), and it made sense to have a helper to find the boundary
between the payload and its signature in tag.c back then.
Newer code added later to parse other kind
Earlier, ffb6d7d5 (Move commit GPG signature verification to
commit.c, 2013-03-31) moved this helper that used to be in pretty.c
(i.e. the output code path) to commit.c for better reusability.
It was a good first step in the right direction, but still suffers a
myopic view that commits will be the
With the interim protocol, we used to send the update commands even
though we already send a signed copy of the same information when
push certificate is in use. Update the send-pack/receive-pack pair
not to do so.
The notable thing on the receive-pack side is that it makes sure
that there is no
The main loop over remote_refs list inspects the ref status
to see if we need to generate pack data (i.e. a delete-only push
does not need to send any additional data), resets it to "expecting
the status report" state, and formats the actual update commands
to be sent.
Split the former two out of
Reusing the GPG signature check helpers we already have, verify
the signature in receive-pack and give the results to the hooks
via GIT_PUSH_CERT_{SIGNER,KEY,STATUS} environment variables.
Policy decisions, such as accepting or rejecting a good signature by
a key that is not fully trusted, is left
Everywhere else we use PKT-LINE to denote the pkt-line formatted
data, but "shallow/deepen" messages are described with PKT_LINE().
Fix them.
Signed-off-by: Junio C Hamano
---
Documentation/technical/pack-protocol.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Docum
The variable counts how many non-deleting command is being sent, but
is only checked with 0-ness to decide if we need to send the pack
data.
Signed-off-by: Junio C Hamano
---
send-pack.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index c1
A run of 'var ? " var" : ""' fed to a long printf string in a deeply
nested block was hard to read. Move it outside the loop and format
it into a strbuf.
As an added bonus, the trick to add "agent=" by using
two conditionals is replaced by a more readable version.
Signed-off-by: Junio C Hamano
A new helper function ref_update_to_be_sent() decides for each ref
if the update is to be sent based on the status previously set by
set_ref_status_for_push() and also if this is a mirrored push.
Signed-off-by: Junio C Hamano
---
send-pack.c | 36 +---
1 file chan
We tried to avoid sending one extra byte, NUL and nothing behind it
to signal there is no protocol capabilities being sent, on the first
command packet on the wire, but it just made the code look ugly.
Signed-off-by: Junio C Hamano
---
send-pack.c | 4 +---
1 file changed, 1 insertion(+), 3 dele
20e8b465 (refactor ref status logic for pushing, 2010-01-08)
restructured the code to set status for each ref to be pushed, but
did not quite go far enough. We inspect the status set earlier by
set_refs_status_for_push() and then perform yet another update to
the status of a ref with an otherwise
Make a helper function to accept a line of a protocol message and
queue an update command out of the code from read_head_info().
Signed-off-by: Junio C Hamano
---
builtin/receive-pack.c | 50 +-
1 file changed, 29 insertions(+), 21 deletions(-)
di
An "update" command in the protocol exchange consists of 40-hex old
object name, SP, 40-hex new object name, SP, and a refname, but the
first instance is further followed by a NUL with feature requests.
The command structure, which has a flex-array member that stores the
refname at the end, was al
This piece of code reads object names of shallow boundaries,
not old_sha1[].
Signed-off-by: Junio C Hamano
---
builtin/receive-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 43f35c4..ee855b4 100644
--- a/bu
Ideally, we should have also allowed the first "shallow" to carry
the feature request trailer, but that is water under the bridge
now. This makes the next step to factor out the queuing of commands
easier to review.
Signed-off-by: Junio C Hamano
---
builtin/receive-pack.c | 24 +
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it d
Rename the imap_folder variable to folder and make it a member
of struct imap_server_conf.
Signed-off-by: Bernhard Reiter
---
As discussed in
http://www.mail-archive.com/git@vger.kernel.org/msg57019.html
Bernhard
imap-send.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
dif
On Tue, Aug 19, 2014 at 03:23:36PM -0500, Robert Dailey wrote:
> On Tue, Aug 19, 2014 at 2:30 PM, Heiko Voigt wrote:
> > Well the remote for the submodule is currently only calculated once,
> > when you do the initial
> >
> > git submodule update --init
> >
> > that clones the submodule. A
Am 19.08.2014 19:15, schrieb Robin Rosenberg:
> Using the original filename suffix for the temporary input files to
> the merge tool confuses IDEs like Eclipse. This patch introduces
> a configurtion option, mergetool.tmpsuffix, which get appended to
> the temporary file name. That way the user can
On Tue, Aug 19, 2014 at 2:30 PM, Heiko Voigt wrote:
> Well the remote for the submodule is currently only calculated once,
> when you do the initial
>
> git submodule update --init
>
> that clones the submodule. Afterwards the fixed url is configured under
> the name 'origin' in the submod
On Tue, Aug 19, 2014 at 2:19 PM, Junio C Hamano wrote:
>
> I do not know if that is how GitHub teaches people, but I would have
> to say that these are strange phrasing. I suspect that part of
> their documentation was written long time ago, back when nobody on
> the GitHub side were involved in
List, please see here an overview and ordering of the ref transaction
patch series.
These series build on each other and needs to be applied in the order
listed below.
This is an update.
rs/ref-transaction-0
---
Early part of the "ref transaction" topic.
* rs/r
On Tue, Aug 19, 2014 at 11:50:08AM -0500, Robert Dailey wrote:
> Maybe I'm misunderstanding something here and you can help me out.
>
> All the reading I've done (mostly github) says that 'upstream' points
> to the authoritative repository that you forked from but do not have
> permissions to writ
Robert Dailey writes:
> Maybe I'm misunderstanding something here and you can help me out.
>
> All the reading I've done (mostly github) says that 'upstream' points
> to the authoritative repository that you forked from but do not have
> permissions to write to. 'origin' points to the place you p
Merge prepare_run_command_v_opt() and its only caller. This removes a
pointer indirection and allows to initialize the struct child_process
using CHILD_PROCESS_INIT.
Signed-off-by: Rene Scharfe
---
run-command.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
di
Signed-off-by: Rene Scharfe
---
run-command.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/run-command.c b/run-command.c
index 47ab21b..9196ee0 100644
--- a/run-command.c
+++ b/run-command.c
@@ -577,9 +577,7 @@ static void prepare_run_command_v_opt(struct child_process
Add a helper function for initializing those struct child_process
variables for which the macro CHILD_PROCESS_INIT can't be used.
Suggested-by: Jeff King
Signed-off-by: Rene Scharfe
---
Documentation/technical/api-run-command.txt | 8 ++--
connect.c | 6 +++
Most struct child_process variables are cleared using memset first after
declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to
initialize them statically instead. That's shorter, doesn't require a
function call and is slightly more readable (especially given that we
already have S
Torsten Bögershausen writes:
> Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is
> incorrectly set on Mingw git. However, the Makefile variable is not
> propagated to the C preprocessor and results in no change. This patch
> pushes the definition to the C code and adds a test t
Robin Rosenberg writes:
> Using the original filename suffix for the temporary input files to
> the merge tool confuses IDEs like Eclipse. This patch introduces
> a configurtion option, mergetool.tmpsuffix, which get appended to
> the temporary file name. That way the user can choose to use a
> s
Bernhard Reiter writes:
> Use libcurl's high-level API functions to implement git-imap-send
> instead of the previous low-level OpenSSL-based functions.
>
> Since version 7.30.0, libcurl's API has been able to communicate with
> IMAP servers. Using those high-level functions instead of the curren
Using the original filename suffix for the temporary input files to
the merge tool confuses IDEs like Eclipse. This patch introduces
a configurtion option, mergetool.tmpsuffix, which get appended to
the temporary file name. That way the user can choose to use a
suffix like ".tmp", which does not ca
Bernhard Reiter writes:
> Am 2014-08-17 um 20:42 schrieb Jeff King:
>> [...]
>>
I'm not sure I understand this comment. Even if SSL is not in use,
wouldn't we be passing a regular pipe to curl, which would break?
>>>
>>> Yeah, we can't do that, and thus would have to keep the handwritt
Robin Rosenberg writes:
> Using the original filename suffix for the temporary input files to
> the merge tool confuses IDEs like Eclipse. This patch introduces
> a configurtion option, mergetool.tmpsuffix, which get appended to
> the temporary file name. That way the user can choose to use a
> s
Jeff King writes:
> On Tue, Aug 19, 2014 at 04:05:21PM +1000, Babak M wrote:
>
>> I saw that if a hook file is present in .git/hooks and it does not
>> have execution permissions it is silently ignored.
>>
>> I thought it might be worthwhile issuing a warning such as "Warning:
>> pre-commit hook
On Tue, Aug 19, 2014 at 11:39 AM, Junio C Hamano wrote:
> Robert Dailey writes:
>
>> The way I set up my remote tracking branch will be different for each
>> of these commands:
>>
>> - git pull :: If I want convenient pulls (with rebase), I will track
>> my upstream branch. My pushes have to be m
Robert Dailey writes:
> The way I set up my remote tracking branch will be different for each
> of these commands:
>
> - git pull :: If I want convenient pulls (with rebase), I will track
> my upstream branch. My pushes have to be more explicit as a tradeoff.
Keeping 'origin' pointing at the rep
Export a generic is_refname_available() function. We will need this
as a public shared function later when we add additional refs backends
since we want to keep using the same rules for ref naming across
all backends.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 29 ++---
These functions do not contain any backend specific code so we can move
them to the common code and share across all backends.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 202
refs.c | 202
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 9 -
refs.c | 9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/refs-be-files.c b/refs-be-files.c
index 6542969..fb9c614 100644
--- a/refs-be-files.c
+++ b/refs-be-files.c
@@ -1747,15 +1747,6 @@ int fo
This function can be shared across all refs backends so move it
to the common code.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 6 --
refs.c | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/refs-be-files.c b/refs-be-files.c
index a94378e..ed7bc61 1
These functions do not use any backend specific code so we can move
them to the common code.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 52
refs.c | 52
2 files changed, 5
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 81 -
refs.c | 81 +
2 files changed, 81 insertions(+), 81 deletions(-)
diff --git a/refs-be-files.c b/refs-be-files.c
ind
This function does not contain any backend specific code so we
can move it to the common code.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 110
refs.c | 110
2 file
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 7 +--
refs.c | 10 ++
refs.h | 5 +
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/refs-be-files.c b/refs-be-files.c
index b09f0fc..910663b 100644
--- a/refs-be-files.c
+++ b/refs-be-files.c
These functions do not depend on the backend implementation so we
can move them to the common code.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 18 --
refs.c | 18 ++
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/refs-be-files.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 5 -
refs.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/refs-be-files.c b/refs-be-files.c
index 55bced9..70c034c 100644
--- a/refs-be-files.c
+++ b/refs-be-files.c
@@ -2483,11 +2483,6 @@ static int log
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 15 ---
refs.c | 15 +++
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/refs-be-files.c b/refs-be-files.c
index 9aa88ef..e58a7e1 100644
--- a/refs-be-files.c
+++ b/refs-be-files.c
@@ -1635,21 +
Add a ref structure for backend methods. Start by adding method pointers
for the transaction functions.
Rename the existing transaction functions to files_* and make them static.
Add new transaction functions that just pass through to the appropriate
methods for the backend.
Signed-off-by: Ronnie
This change moves read_ref_at() to the refs.c file since this function
does not contain any backend specific code.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 114
refs.c | 114
Create a new erfs.c file that will be used to hold all the refs
code that is backend agnostic and will be shared across all backends.
The reason we renamed everything to refs-be-files.c in the previous patch
and now start moving the common code back to the new refs.c file
instead of the other way
Add ref backend methods for:
resolve_ref_unsafe, is_refname_available, pack_refs, peel_ref,
create_symref, resolve_gitlink_ref.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 25 ++---
refs.c | 33 +
refs.h | 18
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 21 ++---
refs.c | 36
refs.h | 18 ++
3 files changed, 68 insertions(+), 7 deletions(-)
diff --git a/refs-be-files.c b/refs-be-files.c
index 910663b..7c0ab
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 21 +++--
refs.c | 32
refs.h | 16
3 files changed, 63 insertions(+), 6 deletions(-)
diff --git a/refs-be-files.c b/refs-be-files.c
index 27eafd0..464d488 100
This change moves the hidden refs functions to the refs.c file since
these functions do not contain any backend specific code.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 43 ---
refs.c | 44
2
This change moves update_ref() to the refs.c file since this function
does not contain any backend specific code.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 23 ---
refs.c | 25 +
2 files changed, 25 insertions(+), 23 deletions(-)
d
This change moves rename_ref() to the refs.c file since this function
does not contain any backend specific code.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 92 -
refs.c | 92 ++
List, please review
This series is called backend-struct-db and is also available at
https://github.com/rsahlberg/git/tree/backend-struct-db
This series is built on and follows after the series
ref-transactions-send-pack
This series does not change any logic or behaviour but mainly just shuffle
Move names_conflict to the common code and make it public.
We want to use the same name conflict checks across all backends
so we guarantee compatibility across backends.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 14 --
refs.c | 8
refs.h | 9 +
This change moves delete_ref() to the refs.c file since this function
does not contain any backend specific code.
Signed-off-by: Ronnie Sahlberg
---
refs-be-files.c | 19 ---
refs.c | 19 +++
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git
Update receive-pack to use an atomic transaction IFF the client negotiated
that it wanted atomic-push.
This leaves the default behaviour to be the old non-atomic one ref at a
time update. This is to cause as little disruption as possible to existing
clients. It is unknown if there are client script
Signed-off-by: Ronnie Sahlberg
---
builtin/receive-pack.c | 6 +-
send-pack.c| 12 +---
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 0565b94..f6b20cb 100644
--- a/builtin/receive-pack.c
+++ b/builtin
Add a configuration argument to the receive side to force atomic pushes
for all pushes to the repo.
Signed-off-by: Ronnie Sahlberg
---
Documentation/config.txt | 5 +
builtin/receive-pack.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/
Signed-off-by: Ronnie Sahlberg
---
Documentation/git-send-pack.txt | 7 ++-
builtin/send-pack.c | 6 +-
send-pack.c | 8 +++-
send-pack.h | 1 +
4 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-send-p
Signed-off-by: Ronnie Sahlberg
---
Documentation/git-push.txt | 7 ++-
builtin/push.c | 2 ++
transport.c| 1 +
transport.h| 1 +
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
List,
This small patch series adds atomic-push support for pushes.
By default git will use the old style non-atomic updates for pushes,
as not to cause disruption in client scripts that may depend on that
behaviour.
Command line arguments are introduced to allow the client side to request/
negoti
Signed-off-by: Ronnie Sahlberg
---
refs.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index 0aad8c8..cfe1292 100644
--- a/refs.c
+++ b/refs.c
@@ -2270,13 +2270,17 @@ static int write_packed_entry_fn(struct ref_entry
*entry, void
Signed-off-by: Ronnie Sahlberg
---
builtin/pack-refs.c | 8 +++-
refs.c | 13 ++---
refs.h | 3 ++-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/builtin/pack-refs.c b/builtin/pack-refs.c
index b20b1ec..299768e 100644
--- a/builtin/pack-re
Get rid of the action_on_err enum and replace the action argument to
update_ref with a strbuf *err for error reporting.
Update all callers to the new api including two callers in transport*.c
which used the literal 0 instead of an enum.
Signed-off-by: Ronnie Sahlberg
---
builtin/checkout.c |
Change add_packed_ref to return an error instead of calling die().
Update all callers to check the return value of add_packed_ref.
We can also skip checking the refname format since this function is now
static and only called from the transaction code.
If we are updating a ref and the refname is b
Signed-off-by: Ronnie Sahlberg
---
refs.c | 85 +++---
1 file changed, 50 insertions(+), 35 deletions(-)
diff --git a/refs.c b/refs.c
index cfe1292..19e73f3 100644
--- a/refs.c
+++ b/refs.c
@@ -2232,8 +2232,8 @@ static struct ref_lock *
List,
This is the next patch series in the ref transaction work.
This patch series is called ref-transactions-req-strbuf-err and builds ontop
of the series called ref-transactions-req-packed-refs which is origin/pu
This patch series mainly adds some nice strbuf arguments to some functions to
pas
On Tue, Aug 19, 2014 at 5:24 AM, Heiko Voigt wrote:
> I think the OP problem stems from him having a branch that does not have a
> remote configured. Since they do not have 'origin' as a remote and
>
> git submodule update --init --recursive path/to/submodule
>
> fails. Right?
Not exactly
On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder wrote:
> Thanks for reporting. The remote used is the default remote that "git
> fetch" without further arguments would use:
>
> get_default_remote () {
> curr_branch=$(git symbolic-ref -q HEAD)
> curr_branch
On 19 August 2014 01:12, Jeff King wrote:
> This is because v2.1.0 started using "make perf" to feed the profile
> builds, but it doesn't work on tarballs.
Thanks for the explanation.
--
Andrés
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord.
Using the original filename suffix for the temporary input files to
the merge tool confuses IDEs like Eclipse. This patch introduces
a configurtion option, mergetool.tmpsuffix, which get appended to
the temporary file name. That way the user can choose to use a
suffix like ".tmp", which does not ca
> -Original Message-
> From: Jeff King
> Sent: Tuesday, August 19, 2014 4:05
>
> On Sun, Aug 17, 2014 at 09:30:47AM -0400, Jason Pyeron wrote:
>
> > I am working on an open source project right now where we
> are looking
> > to enforce a N of M audit approval process. It turns out that g
Am 19.08.2014 um 14:22 schrieb Robin Rosenberg:
> Using the original filename suffix for the temporary input files to
> the merge tool confuses IDEs like Eclipse. This patch introduces
> a configurtion option, mergetool.tmpsuffix, which get appended to
> the temporary file name. That way the user c
Using the original filename suffix for the temporary input files to
the merge tool confuses IDEs like Eclipse. This patch introduces
a configurtion option, mergetool.tmpsuffix, which get appended to
the temporary file name. That way the user can choose to use a
suffix like ".tmp", which does not ca
On Tue, Aug 19, 2014 at 6:11 PM, Steven Evergreen
wrote:
> Hi, everyone. I'm trying to perform a shallow clone with visibility of
> all remote branches.
>
> git clone REPO --depth 1 --no-single-branch
>
> is consistently giving me
>
> Cloning into 'REPONAME'...
> fatal: (null) is unknown object
>
> Maybe we should do this:
Looks good to me.
> As a side note, while testing this I noticed that the "make perf" run
> goes a lot faster if you set GIT_PERF_REPEAT_COUNT=1. This is bad for
> actually measuring things, but probably fine for profile feedback. I
> don't use the profile builds myself
1 - 100 of 109 matches
Mail list logo
