Linus Torvalds schrieb am 21.10.2014 um 01:17:
On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
It doesn't appear that the stability of git archive --format=tar is
documented anywhere. Given that, it doesn't seem reasonable to expect
that any tar
Joseph Nahmias schrieb am 20.10.2014 um 23:24:
Hello,
It would be great if the documentation showed that the git-difftool(1)
command accepted the --cached option. You can probably steal appropriate
verbiage from the git-diff(1) manpage.
$ git --version
git version 2.1.1
Thanks,
Hi all,
Could we add a default to --date so that:
git reflog --date
just works? (Currently you need to do: git reflog --date=iso) It
should probably obey the default in log.date?
Also, could we add this --date option to the man page please? It's
an extremely useful option to know. At
On Mon, Oct 20, 2014 at 11:40:23AM -0700, Junio C Hamano wrote:
Sebastian Schuberth sschube...@gmail.com writes:
Perhaps something like this, so that existing users can still use
bc3 and other people can use bc if it bothers them that they
have to say 3 when the backend driver works with
Jakob Stoklund Olesen stokl...@2pi.dk wrote:
Yes, but I think you can remove cached_mergeinfo_rev too.
Thanks, pushed the patch at the bottom, too.
Also started working on some memory reductions here:
http://mid.gmane.org/20141021033912.ga27...@dcvr.yhbt.net
But there seem to be more problems
On ma, 2014-10-20 at 16:29 +0200, Dennis Kaarsemaker wrote:
Since a few days, one of our repos is causing problems during git fetch,
basically git fetch over http hangs during find_common. When using ssh,
this does not happen.
snip things that may not be relevant.
And for the hanging
This stk shadows the first declaration at the top. There's currently
no bad effect. But let's avoid it.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index bd274a7..3f7a025 100644
--- a/dir.c
+++
Hi Brian,
My Open SSL vendor is IBM. In fact I am using AIX OS from IBM. When we (Myself
and Frank. Frank is cc'ed in this email) discussed with IBM team, they asked
some details on what flag settings need to be used to recompile, what parameter
settings they need to do, etc. IBM team told it
Hello,
Please send me a price list and quotation for your products we want to import
from your country this is a very large order for long term import and urgent
request.
Thank you in advance for your prompt confirmation.
Regards,
Parker Nick
Equipos de Elevaci n , S.A. de C.V.Av. Texcoco
By not clearing the request buffer in stateless-rpc mode, fetch-pack
would keep sending already known-common commits, leading to ever bigger
http requests, eventually getting too large for git-http-backend to
handle properly without filling up the pipe buffer in inflate_request.
---
I'm still not
On Tue, Oct 21, 2014 at 1:08 AM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries. And that clearly wasn't the case (for
extended metadata headers) before Brian's fix.
Hey, it's time for another
John Tapsell johnf...@gmail.com writes:
Hi all,
Could we add a default to --date so that:
git reflog --date
just works? (Currently you need to do: git reflog --date=iso) It
should probably obey the default in log.date?
Hmph. --date=style is not the way to choose between timed and
Linus Torvalds torva...@linux-foundation.org writes:
On Tue, Oct 21, 2014 at 1:08 AM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries. And that clearly wasn't the case (for
extended metadata
For me, writing git reflog @{now} is a lot less intuitive than git
reflog --date
Currently the top google search for this question is here:
http://stackoverflow.com/questions/17369254/is-there-a-way-to-cause-git-reflog-to-show-a-date-alongside-each-entry
Which doesn't mention @{now} at all.
Dennis Kaarsemaker den...@kaarsemaker.net writes:
By not clearing the request buffer in stateless-rpc mode, fetch-pack
would keep sending already known-common commits, leading to ever bigger
http requests, eventually getting too large for git-http-backend to
handle properly without filling up
John Tapsell johnf...@gmail.com writes:
For me, writing git reflog @{now} is a lot less intuitive than git
reflog --date
Currently the top google search for this question is here:
Great - now I just need to persuade someone very nice nicely.. :-)
On 21 October 2014 19:06, Junio C Hamano gits...@pobox.com wrote:
John Tapsell johnf...@gmail.com writes:
For me, writing git reflog @{now} is a lot less intuitive than git
reflog --date
Currently the top google search for
Michael J Gruber g...@drmicha.warpmail.net writes:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries.
Is an extended pax header an archive entry? I doubt it, and the
above is not relevant. The mode bits for the archive entry that it
applies to
David Aguilar dav...@gmail.com writes:
Otherwise, this patch looks like the right way to go ~ it makes
bc available and keeps compatibility for bc3.
OK, thanks. Here is what I'll queue.
-- 8 --
From: Junio C Hamano gits...@pobox.com
Date: Mon, 20 Oct 2014 15:49:36 -0700
Subject: [PATCH]
Konstantin Ryabitsev konstan...@linuxfoundation.org writes:
On 20/10/14 06:28 PM, brian m. carlson wrote:
Junio, quite frankly, I don't think that that fix was a good idea. I'd
suggest having a *separate* umask for the pax headers, so that we do
not break this long-lasting stability of git
Zoltan Klinger zoltan.klin...@gmail.com writes:
When git grep is run with combined patterns such as '-e p1 --and -e p2'
and surrounding context lines are requested, the output contains
incorrectly highlighted matches.
Consider the following output (highlighted matches are surrounded by '*'
commit 8d0a342375fbd926ae6ae93f9be42a436a787fb6 upstream.
Add a flag that allows us to truncate the reflog before we write the
update.
Change-Id: I187b22e0910499b1976689b46866698b6fd46eb3
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
commit de045215a52a6a9591b0e786488de2293d79d245 upstream.
Define a new transaction update type, UPDATE_LOG, and a new function
transaction_update_reflog. This function will lock the reflog and append
an entry to it during transaction commit.
Change-Id: I8cc935ef311688d561d447fa51b44ac98492693b
commit 8f78d5d7a1e62f04c75524bb3e87aaad24372250 upstream.
log_ref_setup is used to do several semi-related things :
* sometimes it will create a new reflog including missing parent directories
and cleaning up any conflicting stale directories in the path.
* fill in a filename buffer for the
commit 03001144a015f81db5252005841bb78f57d62774 upstream.
The ref_transaction_update function can already be used to create refs by
passing null_sha1 as the old_sha1 parameter. Simplify by replacing
transaction_create with a thin wrapper.
Change-Id: I687dd47cc4f4e06766e8313b4fd1b07cd4a56c1a
commit a4369f77d1975566bcd29bfa46720d48372c241d upstream.
unlock|close|commit_ref can be made static since there are no more external
callers.
Change-Id: I743f9daaa1c101fdc781a76283c2e8b462591d07
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
commit 07baa71eda8d1047f003acc7ea32ad6b6600b179 upstream.
Break out the code to create the string and writing it to the file
descriptor from log_ref_write and into a dedicated function log_ref_write_fd.
For now this is only used from log_ref_write but later on we will call
this function from
commit 0beeda259297c92d411ecc92fa508ec7cfd87cc5 upstream.
Change-Id: I685291986e544a8dc14f94c73b6a7c6400acd9d2
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
refs.c | 22 ++
refs.h | 2 +-
2 files changed, 3
List,
Please find a patch that updates the reflog handling to use transactions.
This patch series has previously been sent to the list but is now rebased on
the current content of next which contains ref changes we depend on in this
series.
This series converts the reflog handling and
commit 5fd1fa7d8520cf03e94fa7d0e9aa8685de0ef63f upstream.
Allow to make multiple reflog updates to the same ref during a transaction.
This means we only need to lock the reflog once, during the first update
that touches the reflog, and that all further updates can just write the
reflog entry
commit fd304abafb351f509b105da2d648298efd78df18 upstream.
Rename the transaction functions. Remove the leading ref_ from the
names and append _ref to the names for functions that create/delete/
update sha1 refs.
This also makes the names more appropriate for future changes that have been
commit 020ed65a12838bdead64bc3c5de249d3c8f5cfd8 upstream.
When performing a reflog transaction update, only write to the reflog iff
msg is non-NULL. This can then be combined with REFLOG_TRUNCATE to perform
an update that only truncates but does not write.
Change-Id:
commit 3a2f55c247ff290943fd552674e226062c13fd00 upstream.
No one is using this function so we can delete it.
Change-Id: I524dac239da500e5d4432328b997ed8ab34f6803
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
refs.c | 7 ---
refs.h |
commit 8d75baa250c0f84cc438568cb53ef1a9dd3dfec9 upstream.
Add back support to make it possible to delete refs that have a broken
sha1.
Add new internal flags REF_ALLOW_BROKEN and RESOLVE_REF_ALLOW_BAD_SHA1
to pass intent from branch.c that we are willing to allow
resolve_ref_unsafe and
commit 5ac378cd8fad09a836d17fec379780854838bde5 upstream.
Use a transaction for all updates during expire_reflog.
Change-Id: Ieb81b2660cefeeecf0bcb3cdbc1ef3cbb86e7eb8
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/reflog.c | 85
commit 306805ccd147bfdf160b288a8d51fdf9b77ae0fa upstream.
Update copy_fd to return a meaningful errno on failure.
Change-Id: I771f9703acc816902affcf35ff2a56d9426315ac
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
copy.c | 15
commit fb5fa1d338ce113b0fea3bb955b50bbb3e827805 upstream.
Make the deletion of refs during a transaction more atomic.
Start by first copying all loose refs we will be deleting to the packed
refs file and then commit the packed refs file. Then re-lock the packed refs
file to stop anyone else from
commit e193c10fc4f9274d1e751cfcdcc4507818e8d498 upstream.
Change lock_ref_sha1_basic to return an error instead of dying when
we fail to lock a file during a transaction.
This function is only called from transaction_commit() and it knows how
to handle these failures.
Change-Id:
Change-Id: I87a1b93c4b4f4a10ad6a9f8e2bb4d53f89b28c4a
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/remote.c | 23 ---
refs.c | 42 +-
refs.h | 2 +-
3 files changed, 30 insertions(+), 37 deletions(-)
Transactions now use packed refs when deleting multiple refs so there is no
need to do it manually from remote.c any more.
Change-Id: I50cf9c4ab0c190b99e2c6c4e2f05abe260b0fe62
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/remote.c | 80
write_ref_sha1 tries to update the reflog while updating the ref.
Move these reflog changes out into its own function so that we can do the
same thing if we write a sha1 ref differently, for example by writing a ref
to the packed refs file instead.
No functional changes intended. We only move
Change-Id: Ibfc64ab19257484129ab0ad861b72c02414388df
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index e0d5a82..7fb0d6c 100644
--- a/refs.c
+++ b/refs.c
@@ -2393,13
commit 0295e9cebc41020ee84da275549b164a8770ffba upstream.
Change refs.c to use a single transaction to copy/rename both the refs and
its reflog. Since we are no longer using rename() to move the reflog file
we no longer need to disallow rename_ref for refs with a symlink for its
reflog so we can
List,
Thsi series builds on the previous series : ref-transaction-reflog
as applied to next. This series has been sent to the list before
but is now rebased to current git next.
This series can also be found at :
https://github.com/rsahlberg/git/tree/ref-transactions-rename
This series converts
When we are updating more than one single ref, i.e. not a commit, then
write the updated refs directly to the packed refs file instead of writing
them as loose refs.
Change clone to use a transaction instead of using the packed refs API.
This changes the behavior of clone slightly. Previously
Change add_packed_ref to return an error instead of calling die().
Update all callers to check the return value of add_packed_ref.
Change-Id: I5d5e4a75f641c4bbdb59199a233b71e86361c25c
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 21 +
1 file changed, 17
commit 167e0c6d205ed785cc17b96e22d9366accfa1665 upstream.
In many places in the code we do not have access to the individual fields
in the committer data. Instead we might only have access to prebaked data
such as what is returned by git_committer_info() containing a string
that consists of
Change-Id: Ibf02549e5485ad07da66fe4b1c84f9e2b76b2aca
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 2 +-
refs.h | 3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index b64d0c7..fddd59c 100644
--- a/refs.c
+++ b/refs.c
@@ -2663,7 +2663,7 @@
Add a command line argument to the git push command to request atomic
pushes.
Change-Id: I9f8d06970b2fdd1cf7d933e0cce1288752034af1
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
Documentation/git-push.txt | 7 ++-
builtin/push.c | 2 ++
transport.c| 1 +
Change-Id: I812e7600fb648df429df8a2c84745de4f5875626
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/branch.c | 7 +--
builtin/checkout.c | 13 ++---
builtin/clone.c| 15 +++
builtin/init-db.c | 8 ++--
builtin/notes.c|
This adds support to the protocol between send-pack and receive-pack to
* allow receive-pack to inform the client that it has atomic push capability
* allow send-pack to request atomic push back.
There is currently no setting in send-pack to actually request that atomic
pushes are to be used yet.
Change-Id: I1e65ac429c14f01073d95c6440f820dda1c6091b
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/pack-refs.c | 8 +++-
refs.c | 7 +++
refs.h | 3 ++-
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/builtin/pack-refs.c
Change-Id: I3a6491515b78b564d1cc0892826a4bc77f9bffb0
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
t/t5543-atomic-push.sh | 101 +
1 file changed, 101 insertions(+)
create mode 100755 t/t5543-atomic-push.sh
diff --git
We no longer need to expose the lock/add/commit/rollback functions
for packed refs anymore so make them static and remove them from the
public api.
Change-Id: I1059f1690129f0232cb27872ef494024ef7f299e
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 8
refs.h | 30
Add receive.preferatomicpush setting to receive-pack.c. This triggers
a new capability prefer-atomic-push to be sent back to the send-pack
client, requesting the client, if it supports it, to request
an atomic push.
This is an alternative way to trigger an atomic push instead of having
to rely of
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.
Change-Id: I8ee1540380393380b5a06db380fb8491bfe1ecdd
List,
This series has been posted before but is now rebased on the previous
ref-transaction-rename series that are against next.
This series can also be found at :
https://github.com/rsahlberg/git/tree/ref-transactions-send-pack
This series finishes the transaction work to provide atomic pushes.
This adds support to send-pack to to negotiate and use atomic pushes
iff the server supports it. Atomic pushes are activated by a new command
line flag --atomic-push.
In order to do this we also need to change the semantics for send_pack()
slightly. The existing send_pack() function actually
Add err argument to create_reflog that can explain the reason for a
failure. This then eliminates the need to manage errno through this
function since we can just add strerror(errno) to the err string when
meaningful. No callers relied on errno from this function for anything
else than the error
commit 3989c2a763c3b355785d609b3144c7935dffb273 upstream.
Change-Id: I63a22da521ecc8eb60d7a8aaa5af666d2827a599
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
refs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Update receive-pack to use an atomic transaction iff the client negotiated
that it wanted atomic-push.
This leaves the default behavior 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
Junio C Hamano gits...@pobox.com writes:
Things might have been different if this were mid 2006 or early
2007, but I am afraid that the spirit of git with a quote from
Linus no longer carries much weight on this particular issue. A
backward incompatible change is backward incompatible change
Trying to be as strict as possible when applying the patch may be a
good discipline, so let's flip the default but we can be helpful to
those who do rely on the original behaviour thanks to the previous
change to add -C$n option.
Suggest using -C1 when (and only when):
- git apply without fuzz
From: Junio C Hamano gits...@pobox.com
Junio C Hamano gits...@pobox.com writes:
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
...
I think it is just the font. I just opened the above page with
Chrome and futzed the text from '0' to '0123456789' to see how
Newer web rendering of 'git status --help --web' shows the zero in
NUL (ASCII 0) as if it is a small 'o' character. Back-tick quote the
zero to ensure it is displayed as a full size mono-spaced font. Also
display the double quote (ASCII 34) in the same manner.
Signed-off-by: Philip Oakley
Junio C Hamano gits...@pobox.com writes:
John Tapsell johnf...@gmail.com writes:
For me, writing git reflog @{now} is a lot less intuitive than git
reflog --date
Currently the top google search for this question is here:
Junio C Hamano gits...@pobox.com writes:
If your goal is to stop colouring words on context and other kinds
of lines, do you still need the while (next_match(...)) loop for
them? Can't you make the resulting code clearer by restructuring
the inside of the whole if (opt-color) block further,
John Tapsell johnf...@gmail.com writes:
On 21 October 2014 19:06, Junio C Hamano gits...@pobox.com wrote:
John Tapsell johnf...@gmail.com writes:
For me, writing git reflog @{now} is a lot less intuitive than git
reflog --date
Currently the top google search for this question is here:
Hello,
Please send me a price list and quotation for your products we want to import
from your country this is a very large order for long term import and urgent
request.
Thank you in advance for your prompt confirmation.
Regards,
Parker Nick
Equipos de Elevaci n , S.A. de C.V.Av. Texcoco
Junio C Hamano gits...@pobox.com writes:
It turns out that the result of such a change becomes more readable
than the original, in that it makes it clear that reinspection of
the lines are done only for matched ones and not context lines.
Agree, it looks much clearer now. Happy if you
On Tue, Oct 21, 2014 at 12:31:55PM +, ravikirangoud_palpano...@vfc.com
wrote:
Hi Brian,
My Open SSL vendor is IBM. In fact I am using AIX OS from IBM. When we
(Myself and Frank. Frank is cc'ed in this email) discussed with IBM
team, they asked some details on what flag settings need to
71 matches
Mail list logo
