This teaches the deepest part of the callchain for git push (and
git send-pack) to enforce the old value of the ref must be this,
otherwise fail this push (aka compare-and-swap / --lockref).
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/send-pack.c | 5 +
remote.c|
This plugs the push_cas_option data collected by the command line
option parser to the transport system with a new function
apply_push_cas(), which is called after match_push_refs() has
already been called.
At this point, we know which remote we are talking to, and what
remote refs we are going
This is mostly unchanged since the previous round, except that
* The option is spelled --force-with-lease=ref:expect.
Nobody liked cas as it was too technical, many disliked
lockref because lock sounded as if push by others were
excluded by it while in fact this is to fail us.
The
The command line parser of git push for --tags, --delete, and
--thin options still used outdated OPT_BOOLEAN. Because these
options do not give escalating levels when given multiple times,
they should use OPT_BOOL.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/push.c | 6 +++---
1
The definition of struct ref in cache.h, a header file so
central to the system, always confused me. This structure is not
about the local ref used by sha1-name API to name local objects.
It is what refspecs are expanded into, after finding out what refs
the other side has, to define what refs
Prepare two repositories, src and dst, the latter of which is a
clone of the former (with tracking branches), and push from the
latter into the former, with various --force-with-lease options.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5533-push-cas.sh | 189
Update git push and git send-pack to parse this commnd line
option.
The intended sematics is:
* --force-with-lease alone, without specifying the details, will
protect _all_ remote refs that are going to be updated by
requiring their current value to be the same as some reasonable
Junio C Hamano wrote:
* mv/merge-ff-tristate (2013-07-02) 1 commit
(merged to 'next' on 2013-07-09 at c32b95d)
+ merge: handle --ff/--no-ff/--ff-only as a tri-state option
Sorry I didn't notice sooner, but I was confused by the second test
title this added:
test_expect_success 'option
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
When using pathspec filtering in combination with diff-based log
output, parent simplification happens before the diff is computed.
The diff is therefore against the *simplified* parents.
This works okay,
Hello Thomas,
On Tue, Jul 23, 2013 at 09:27:06AM +0200, Thomas Rast wrote:
Junio C Hamano gits...@pobox.com writes:
Conceptually I can see how this will change the history
simplification in the vertical direction (skipping the ancestry
chain and jumping directly to the closest grandparent
Hi,
On Tue, Jul 23, 2013 at 12:53:25PM +0530, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
* mv/merge-ff-tristate (2013-07-02) 1 commit
(merged to 'next' on 2013-07-09 at c32b95d)
+ merge: handle --ff/--no-ff/--ff-only as a tri-state option
Sorry I didn't
Just the next line assigns a non-null value to seen.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/rm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 5b63d3f..df85f98 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -316,7 +316,6 @@
Junio C Hamano gitster at pobox.com writes:
This is mostly unchanged since the previous round, except that
* The option is spelled --force-with-lease=ref:expect.
Nobody liked cas as it was too technical, many disliked
lockref because lock sounded as if push by others were
'st' is allocated via xmalloc a few lines before and passed to
the stream opening functions.
The xmalloc function is written in a way that either 'st' is allocated
valid memory or xmalloc already dies.
The function calls to open_istream_* do not change 'st', as the pointer is
passed by reference
When handed an empty range_set (range_set.nr == 0),
sort_and_merge_range_set() incorrectly sets range_set.nr to 1 at exit.
Subsequent range_set functions then access the bogus range at element
zero and crash or throw an assertion failure. Fix this bug.
Signed-off-by: Eric Sunshine
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
t/t4211-line-log.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh
index 12814c0..7616365 100755
--- a/t/t4211-line-log.sh
+++ b/t/t4211-line-log.sh
@@ -72,4 +72,9 @@ test_expect_success
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
t/t4211-line-log.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh
index 7776f93..1db1edd 100755
--- a/t/t4211-line-log.sh
+++ b/t/t4211-line-log.sh
@@ -64,4 +64,12 @@ test_bad_opts -L
range-set invariants are: ranges must be (1) non-empty, (2) disjoint,
(3) sorted in ascending order.
During processing, various range-set utility functions break the
invariants (for instance, by adding empty ranges), with the
expectation that a finalizing sort_and_merge_range_set() will restore
range-set invariants are: ranges must be (1) non-empty, (2) disjoint,
(3) sorted in ascending order.
line_log_data_insert() breaks the non-empty invariant under the
following conditions: the incoming range is empty and the pathname
attached to the range has not yet been encountered. In this case,
On Tue, Jul 23, 2013 at 9:06 AM, Duy Nguyen pclo...@gmail.com wrote:
Another is reject new shallow history (i.e.
no additions to .git/shallow) unless the user explicitly asks so
either via --depth or a new option --shallow. This does not mean that
fetching from a shallow clone always fails
Eric Sunshine sunsh...@sunshineco.com writes:
While implementing multiple -L support for git-blame, I encountered
several bugs in range-set and line-log resulting in crashes. This
series fixes those bugs.
Acked-by: Thomas Rast tr...@inf.ethz.ch
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
Thomas Rast tr...@inf.ethz.ch writes:
Now that git log -L has hit master, I figure it's time to discuss the
corresponding change to gitk.
Paul, any news on this? Any chance we can get it into the next release,
since that will also be the first release to ship with 'git log -L'?
--
Thomas
Miklos Vajna vmik...@suse.cz writes:
How is --ff-only overwriting merge.ff=only here? Was it a typo?
Yes, it's a typo in the test name. Thanks for spotting that!
Thanks, will do this:
Subject: [PATCH] t7600: fix typo in test title
Spotted by Ram, confirmed by Miklos.
Signed-off-by: Junio
On Tue, Jul 23, 2013 at 10:28:05AM -0400, Eric Sunshine wrote:
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
t/t4211-line-log.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh
index 7776f93..1db1edd 100755
---
Yamada Saburo devil.tamac...@gmail.com writes:
-#: git-gui.sh:2893
+#: git-gui.sh:2983 git-gui.sh:3115
+msgid Usage
+msgstr 使用状況
Is this correct? I am not familiar with the context this string
appears, but shouldn't it be 使い方?
It is a title of the error box which does not have seeing
Jakub Narebski jna...@gmail.com writes:
Junio C Hamano gitster at pobox.com writes:
This is mostly unchanged since the previous round, except that
* The option is spelled --force-with-lease=ref:expect.
Nobody liked cas as it was too technical, many disliked
lockref because lock
Stefan Beller stefanbel...@googlemail.com writes:
Just the next line assigns a non-null value to seen.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/rm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 5b63d3f..df85f98 100644
On 07/23/2013 08:32 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
Just the next line assigns a non-null value to seen.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/rm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/rm.c
Stefan Beller stefanbel...@googlemail.com writes:
On 07/23/2013 08:32 PM, Junio C Hamano wrote:
Interesting. This is ancient and dates back to 7612a1ef (git-rm:
honor -n flag., 2006-06-08).
Originally it comes from d9b814cc97 (by Linus), which introduced:
+ seen = NULL;
+ if
SZEDER Gábor sze...@ira.uka.de writes:
You could avoid the 'cat' here and patch in 4/5 by doing $(wc -l b.c).
Correct.
(Side question: the test suite is full with similar constructs, i.e.
redirecting file contents to stdin, but why not just use wc -l b.c,
i.e. let wc open the file?)
wc -l
git clone https://git.kernel.org/cgit/git/git.git
Cloning into 'git'...
error: Unable to get pack index
https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx
error: Unable to get pack file
From: Duy Nguyen pclo...@gmail.com
Sent: Tuesday, July 23, 2013 2:28 AM
On Tue, Jul 23, 2013 at 2:23 AM, Philip Oakley philipoak...@iee.org
wrote:
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Subject: [PATCH v2 15/16] config: add core.noshallow to prevent
turning a
repo into a shallow one
Thomas Rast tr...@inf.ethz.ch writes:
+define_commit_slab(saved_parents, struct commit_list *);
+struct saved_parents saved_parents_slab;
+static int saved_parents_initialized;
+
+void save_parents(struct commit *commit)
+{
+ struct commit_list **pp;
+
+ if
On Tue, Jul 23, 2013 at 09:41:44PM +0200, Stefan Beller wrote:
git clone https://git.kernel.org/cgit/git/git.git
Cloning into 'git'...
error: Unable to get pack index
https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx
error: Unable to get
On Tue, Jul 23, 2013 at 12:03:05PM -0700, Junio C Hamano wrote:
SZEDER Gábor sze...@ira.uka.de writes:
(Side question: the test suite is full with similar constructs, i.e.
redirecting file contents to stdin, but why not just use wc -l b.c,
i.e. let wc open the file?)
wc -l b.c is the
On Tue, Jul 23, 2013 at 10:06:05PM +0200, Fredrik Gustafsson wrote:
Confirmed (tested both with and without trailing /, IIRC there was some
configuration change recently that effect that):
iveqy@kolya:~/slask/git$ git clone
https://git.kernel.org/cgit/git/git.git/
Klonar till git...
error:
Jeff King wrote:
then smart HTTP works fine. I wonder if there is a problem in the cgit
setup on kernel.org (or if it was even intended that you could fetch
from the cgit URL at all; the cgit page shows the clone URLs in
/pub/scm/git).
I didn't think cgit URLs were meant to be clonable, but
From: Dave Borowitz dborow...@google.com
HTTP servers may send Set-Cookie headers in a response and expect them
to be set on subsequent requests. By default, libcurl behavior is to
store such cookies in memory and reuse them across requests within a
single session. However, it may also make
On Tue, Jul 23, 2013 at 01:40:05PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
then smart HTTP works fine. I wonder if there is a problem in the cgit
setup on kernel.org (or if it was even intended that you could fetch
from the cgit URL at all; the cgit page shows the clone URLs in
From: Junio C Hamano gits...@pobox.com
Sent: Tuesday, July 23, 2013 7:26 PM
Jakub Narebski jna...@gmail.com writes:
Junio C Hamano gitster at pobox.com writes:
This is mostly unchanged since the previous round, except that
* The option is spelled --force-with-lease=ref:expect.
Nobody
6796d49 introduced a bug by making shared_path == .git/hg' which
will most likely exist already, causing a new remote never to be
cloned and subsequently causing hg.share to fail with error msg:
mercurial.error.RepoError: repository .git/hg not found
Changing gitdir to dirname causes shared_path
On 2013-06-21 11:06, Junio C Hamano wrote:
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
While both GUI and console Cygwin browsers do exist, anecdotal evidence
suggests most users rely on their native Windows browser. cygstart,
which is a long-standing part of the base Cygwin
From: Duy Nguyen pclo...@gmail.com
Sent: Tuesday, July 23, 2013 2:20 AM
On Tue, Jul 23, 2013 at 6:41 AM, Philip Oakley philipoak...@iee.org
wrote:
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Subject: [PATCH v2 00/16] First class shallow clone
It's nice to see that shallow can be a first class
The descriptions of select by numbers section for interactive
git-clean are borrowed from git-add, and one sentence should be
replaced.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
Documentation/git-clean.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Dave Borowitz dborow...@google.com
HTTP servers may send Set-Cookie headers in a response and expect them
to be set on subsequent requests. By default, libcurl behavior is to
store such cookies in memory and reuse them across requests within a
single session. However, it may also make
dborow...@google.com writes:
From: Dave Borowitz dborow...@google.com
HTTP servers may send Set-Cookie headers in a response and expect them
to be set on subsequent requests. By default, libcurl behavior is to
store such cookies in memory and reuse them across requests within a
single
On Tue, Jul 23, 2013 at 3:03 PM, Junio C Hamano gits...@pobox.com wrote:
SZEDER Gábor sze...@ira.uka.de writes:
You could avoid the 'cat' here and patch in 4/5 by doing $(wc -l b.c).
Correct.
Thanks, I like that better.
Unfortunately, what actually got queued on 'next', after applying this
On Tue, Jul 23, 2013 at 5:26 PM, Philip Oakley philipoak...@iee.org wrote:
From: Junio C Hamano gits...@pobox.com
Sent: Tuesday, July 23, 2013 7:26 PM
Jakub Narebski jna...@gmail.com writes:
Junio C Hamano gitster at pobox.com writes:
This is mostly unchanged since the previous round, except
Hi there,
I noticed a change in commit 734b2f0 on
contrib/completion/git-completion.bash which reverted a syntax fix for
'+=' syntax [1], the syntax does not work for bash 3.1. As far as I
know, bash 3.0.x is still widely used on some old servers, could
someone add the fix back again?
Thanks,
On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley philipoak...@iee.org wrote:
In some sense a project with a sub-module is a narrow clone, split at a
'commit' object.
Yes, except narrow clone is more flexible. You have to decide the
split boundary at commit time for sub-module, while you decide
Document for interactive git-clean says: You also could say `c` or
`clean` above as long as the choice is unique. But it's not true,
because only hotkey `c` and full match (`clean`) could work.
Implement partial matching via find_unique function to make the
document right.
Signed-off-by: Jiang
In the 1st version of this patch, I forgot to remove a shell command for
debug in t7301:
find . /tmp/x
Remove the above command in this version. Sorry about this.
Jiang Xin (1):
git-clean: implement partial matching for selection
builtin/clean.c | 80
Document for interactive git-clean says: You also could say `c` or
`clean` above as long as the choice is unique. But it's not true,
because only hotkey `c` and full match (`clean`) could work.
Implement partial matching via find_unique function to make the
document right.
Signed-off-by: Jiang
53 matches
Mail list logo
