Brad King writes:
> Add 'struct ref_update' to encode the information needed to update or
> delete a ref (name, new sha1, optional old sha1, no-deref flag). Add
> function 'update_refs' accepting an array of updates to perform. First
> sort the input array to order locks consistently everywhere
Brad King writes:
> Factor the lock and write steps and error handling into helper functions
> update_ref_lock and update_ref_write to allow later use elsewhere.
> Expose lock_any_ref_for_update's type_p to update_ref_lock callers.
>
> Signed-off-by: Brad King
> ---
> refs.c | 28
On Fri, Aug 30, 2013 at 9:35 AM, Nazri Ramliy wrote:
> This is similar in spirit to to "make -C dir ..." and "tar -C dir ...".
>
> Currently it takes more effort (keypresses) to invoke git command in a
> different directory than the current one without leaving the current
> directory:
>
> 1. (
On 08/29/2013 11:24 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> Do I really need to quote the paragraph in CodingGuidelines?
>>
>> Existing violations are not an excuse to make things worse by adding
>> more. I think with these comments we can expect a re
On 08/29/2013 11:25 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Actually, I think not fixing it inside that 1/8 is good, as there
>> are many existing "cmd > file" (and worse, "cmd > file-$x") in these
>> test-*.sh scripts. Clean-up is better done as a follow-up patch.
>>
>> Here are
On Sat, Aug 31, 2013 at 12:46 AM, René Scharfe wrote:
> Am 29.08.2013 22:36, schrieb Felipe Contreras:
>>
>> On Thu, Aug 29, 2013 at 3:03 PM, René Scharfe wrote:
>>>
>>> If you have a --work-tree option then parseopt accepts --work as well,
>>> unless it's ambiguous, i.e. another option starts wi
On Fri, Aug 30, 2013 at 2:12 PM, Brad King wrote:
> Extend t/t1400-update-ref.sh to cover cases using the --stdin option.
>
> Signed-off-by: Brad King
> ---
> t/t1400-update-ref.sh | 206
> +
> 1 file changed, 206 insertions(+)
>
> diff --git a/t
git-add--interactive.perl rejects arguments with colons in 21e9757
(Hack git-add--interactive to make it work with ActiveState Perl -
2007-08-01). Pathspec magic starts with a colon, so it won't work if
these pathspecs are passed to git-add--interactive.perl running with
ActiveState Perl. Make sure
http://cyno-tavannes.ch/language/comon.php?page=4904127
--
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
For the full discussion:
http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225305
The user still can specify 'git pull --merge' to restore the old
behavior, or 'git config pull.rebase false'.
Signed-off-by: Felipe Contreras
---
Documentation/git-pull.txt| 1 +
builtin/me
This is what the code intended.
No functional changes.
Signed-off-by: Felipe Contreras
---
t/annotate-tests.sh| 2 +-
t/t4200-rerere.sh | 2 +-
t/t9114-git-svn-dcommit-merge.sh | 2 +-
t/t9500-gitweb-standalone-no-errors.sh | 2 +-
4 files changed,
No functional changes.
Signed-off-by: Felipe Contreras
---
builtin/merge.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 34a6166..da9fc08 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -186,13 +186,6 @@ static int o
Junio already sent a similar patch, but I think this is simpler.
Felipe Contreras (3):
merge: simplify ff-only option
t: replace pulls with merges
pull: reject non-ff pulls by default
Documentation/git-pull.txt | 1 +
builtin/merge.c| 20 ++-
From: "Christian Couder"
There were no hints in the documentation about how to create
replacement objects.
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/git-replace.txt
b/Documentation/git-r
From: "Christian Couder"
Subject: [PATCH v3 11/11] t6050-replace: use some long option names
So that they are tested a litlle bit too.
s /litlle/little/
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t605
From: "Christian Couder"
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-replace.txt
b/Documentation/git-replace.txt
index 736b48c..a2bd2ee 100644
--- a/Documentation/git-replace.txt
+++
Sorry for not replying earlier in the series.
From: "Christian Couder"
Users replacing an object with one of a different type were not
prevented to do so, even if it was obvious, and stated in the doc,
that bad things would result from doing that.
To avoid mistakes, it is better to just forbid
So that it's possible to remove certain refs from the list without
removing the objects that are referenced by other refs.
For example this repository:
C (crap)
B (test)
A (HEAD, master)
When using '--branches --except crap':
B (test)
A (HEAD, master)
But when using '--branches --not
Dear Friend,
I decided to contact you to help me actualize this business for the mutual
benefit of both our families. I am the Auditing and Accounting section manager
in a bank, there is one of our customers who have made fixed deposit of sum of
($39.5)million for 7 years and upon maturity;
On Sat, Aug 31, 2013 at 12:57:34PM -0500, Felipe Contreras wrote:
> On Sat, Aug 31, 2013 at 8:58 AM, Max Kirillov wrote:
>> Tha was some of the vim repositories, upstream
>> https://code.google.com/p/vim/ or debian
>> anonscm.debian.org/hg/pkg-vim/vim, or both.
>> They contain tags with ~ symbol.
I always want my diffs to show header files first,
then .c files, then the rest. Make it possible to
set orderfile though a config option to achieve this.
Signed-off-by: Michael S. Tsirkin
---
diff.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/diff.c b/diff.c
index 208094f..cca0767 10
On Fri, Aug 30, 2013 at 6:55 PM, Junio C Hamano wrote:
> People often find "git log --branches" etc. that includes _all_
> branches is cumbersome to use when they want to grab most but except
> some. The same applies to --tags, --all and --glob.
This idea looks very familiar, from the wording of
On Fri, Aug 30, 2013 at 2:56 AM, Johannes Sixt wrote:
> Am 8/30/2013 8:32, schrieb Junio C Hamano:
>> If you have a history where
>>
>> - branches "master" and "maint" point at commit A;
>> - branch "next" points at commit B that is a descendant of A; and
>> - there are tags X and Y pointing at
On Mon, Aug 26, 2013 at 07:57:47PM +0300, Michael S. Tsirkin wrote:
> Consider [anything]-by: a valid signature.
> This includes Tested-by: Acked-by: Reviewed-by: etc.
>
> Signed-off-by: Michael S. Tsirkin
Ping.
Any opinion on whether this change is acceptable?
> ---
> git-send-email.perl | 2
It is now standard practice in Git to have both short and long option
names. So let's give a long option name to the git replace options too.
Signed-off-by: Christian Couder
---
builtin/replace.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/replace.c b/builti
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 736b48c..a2bd2ee 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.
So that they are tested a litlle bit too.
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 0b07a0b..5dc26e8 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@
If -f option, which means '--force', is used, we can allow an object
to be replaced with one of a different type, as the user should know
what (s)he is doing.
Signed-off-by: Christian Couder
---
builtin/replace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/replace
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 05be228..0b07a0b 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -276,6 +276,12 @@ test_expect_success 'replaced and replaceme
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index a2bd2ee..414000e 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -54,13 +5
Users replacing an object with one of a different type were not
prevented to do so, even if it was obvious, and stated in the doc,
that bad things would result from doing that.
To avoid mistakes, it is better to just forbid that though.
If one object is replaced with one of a different type, the
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index decdc33..5c352c4 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -263,4 +263,17 @@ test_expect_success 'not just comm
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c352c4..05be228 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -276,4 +276,10 @@ test_expect_success 'replaced and replaceme
A previous patch ensures that both the replaced and the replacement
objects passed to git replace must be of the same type.
While at it state that there is no other restriction on both objects.
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 7 ---
1 file changed, 4 inse
There were no hints in the documentation about how to create
replacement objects.
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index aa66d27..7
In this new version of the series, the only change in the 5 first
patches, is a small change in the commit message of patch 1.
Patches from 6/11 to 11/11 are all new:
- 6/11, 7/11 and 8/11 are about bypassing the type check
if -f is used
- 9/11, 10/11 and 11/11 are about ad
On 08/30/2013 08:11 PM, Brad King wrote:
> Here is the second revision of a series to support locking multiple
> refs at the same time to update all of them consistently. The first
> series can be found at $gmane/233260. This revision is ready to
> consider for integration.
I'm very interested i
On 08/30/2013 08:12 PM, Brad King wrote:
> Add a --stdin signature to read update instructions from standard input
> and apply multiple ref updates together. Use an input format that
> supports any update that could be specified via the command-line,
> including object names like 'branch:path with
On 08/30/2013 08:12 PM, Brad King wrote:
> Add 'struct ref_update' to encode the information needed to update or
> delete a ref (name, new sha1, optional old sha1, no-deref flag). Add
> function 'update_refs' accepting an array of updates to perform. First
> sort the input array to order locks co
On Sat, Aug 31, 2013 at 8:58 AM, Max Kirillov wrote:
> Felipe Contreras
> gmail.com> writes:
>> Which repository triggered this?
>
> Tha was some of the vim repositories, upstream
> https://code.google.com/p/vim/ or debian
> anonscm.debian.org/hg/pkg-vim/vim, or both.
> They contain tags with ~ s
On Sat, Aug 31, 2013 at 8:58 AM, Max Kirillov wrote:
> Felipe Contreras
> gmail.com> writes:
>> Which repository triggered this?
>
> Tha was some of the vim repositories, upstream
> https://code.google.com/p/vim/ or debian
> anonscm.debian.org/hg/pkg-vim/vim, or both.
> They contain tags with ~ s
On Sat, Aug 31, 2013 at 9:41 AM, Philip Oakley wrote:
> From: "Felipe Contreras"
>>Showing ahead/behind is
>> not as important,
>
>
> I still find this useful - if it's up to date I don't need reminding of
> which remote / upstream tracking branch it's configured against ;-)
Whether or
On Sat, Aug 31, 2013 at 5:28 AM, René Scharfe wrote:
> Am 31.08.2013 11:22, schrieb Felipe Contreras:
>
>> On Sat, Aug 31, 2013 at 4:11 AM, René Scharfe wrote:
>>
Subject: pull: trivial simplification
With that summary, people would have an easier time figuring out if
they nee
On Fri, Aug 30, 2013 at 10:08:53PM +0200, Jens Lehmann wrote:
> Am 30.08.2013 21:51, schrieb Jens Lehmann:
> > Am 30.08.2013 21:40, schrieb Jens Lehmann:
> >> Am 29.08.2013 23:23, schrieb Matthieu Moy:
> >>> Jens Lehmann writes:
> >>>
> Am 29.08.2013 15:05, schrieb Matthieu Moy:
> >>> Because
On Fri, Aug 30, 2013 at 11:39 PM, Kyle J. McKay wrote:
> On Aug 30, 2013, at 11:13, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>> Ævar Arnfjörð Bjarmason writes:
+ binmode $fh, ':utf8';
> What happens if the author name is written in ISO-8859-1 instead of UTF-8 in
> the actua
On 08/30/2013 08:12 PM, Brad King wrote:
> Factor loose ref deletion into helper function delete_ref_loose to allow
> later use elsewhere.
>
> Signed-off-by: Brad King
> ---
> refs.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/refs.c b/refs
I did. I just clumsily sent out the wrong patch. I.e. tested it
manually on another system, and then fat-fingered $fh instead of $fd.
Should I send another patch or do you want to just fix this one up?
On Fri, Aug 30, 2013 at 8:13 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Ævar Arn
Don't know if this has been resolved-by-debate here before, But if
`git-rebase' finds a hitherto untracked file in the worktree, which it
wants to create, it then aborts asking you to remove the file. So if
you remove it and ask git to continue with `git-rebase --continue', it
then deletes the co
From: "Felipe Contreras"
Sent: Friday, August 30, 2013 11:59 PM
Hi,
This has been discussed before:
http://thread.gmane.org/gmane.comp.version-control.git/224489
but in the spirit of the perfect being the enemy of the good, nothing
got done.
This series makes 'git branch -v' much faster, a
Felipe Contreras
gmail.com> writes:
> Which repository triggered this?
Tha was some of the vim repositories, upstream
https://code.google.com/p/vim/ or debian
anonscm.debian.org/hg/pkg-vim/vim, or both.
They contain tags with ~ symbol.
I don't have any experience with bazaar yet, so
cannot
Hi,
if I run rebase --continue (e.g. after a conflict resolution), then the rebase
always ends with this error message:
It seems that there is already a rebase-apply directory, and
I wonder if you are in the middle of another rebase. If that is the
case, please try
On Tue, Aug 27, 2013 at 11:26 AM, Nicolas Pitre wrote:
> A bit crud but good enough for now.
I wonder if we should keep a short SHA-1 table in .idx. An entry in
the original .idx v1 table is + then offset moved out
to make the table more compact for binary search. I observe that we
don't always n
Am 31.08.2013 11:22, schrieb Felipe Contreras:
On Sat, Aug 31, 2013 at 4:11 AM, René Scharfe wrote:
Subject: pull: trivial simplification
With that summary, people would have an easier time figuring out if
they need to read more about the patch or not.
"trivial simplification" is too gener
On Sat, Aug 31, 2013 at 4:11 AM, René Scharfe wrote:
>> Subject: pull: trivial simplification
>>
>> With that summary, people would have an easier time figuring out if
>> they need to read more about the patch or not.
>
>
> "trivial simplification" is too generic; we could have lots of them.
No,
Am 31.08.2013 10:22, schrieb Felipe Contreras:
Subject: branch: use $curr_branch_short more
Why? I don't think that summary explains the reason for being for this
patch, also, it starts with branch: instead of pull:
You're right about "branch" vs. "pull". I'll better go back to bed. ~_~
Su
> Subject: branch: use $curr_branch_short more
Why? I don't think that summary explains the reason for being for this
patch, also, it starts with branch: instead of pull:
Subject: pull: trivial simplification
With that summary, people would have an easier time figuring out if
they need to read m
One of the first things git-pull.sh does is setting $curr_branch to
the target of HEAD and $curr_branch_short to the same but with the
leading "refs/heads/" removed. Use $curr_branch_short in the function
error_on_no_merge_candidates instead of removing the prefix from
$curr_branch directly.
The
On Sat, Aug 31, 2013 at 08:52:06AM +0200, Patrick Atoon wrote:
> Here is what happens. First try cloning without specifying the user name:
>
> ---8<---
> $ git clone https://git.server.com/git/test.git
> Initialized empty Git repository in /tmp/
On Fri, Aug 30, 2013 at 10:58 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> There's no need to remove 'refs/heads/' yet again.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> git-pull.sh | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/git-pull.sh b/git-
On Sat, Aug 31, 2013 at 2:46 AM, René Scharfe wrote:
> Am 29.08.2013 22:36, schrieb Felipe Contreras:
>>
>> On Thu, Aug 29, 2013 at 3:03 PM, René Scharfe wrote:
>>>
>>> If you have a --work-tree option then parseopt accepts --work as well,
>>> unless it's ambiguous, i.e. another option starts wit
Am 29.08.2013 22:36, schrieb Felipe Contreras:
On Thu, Aug 29, 2013 at 3:03 PM, René Scharfe wrote:
If you have a --work-tree option then parseopt accepts --work as well,
unless it's ambiguous, i.e. another option starts with --work, too. So you
can have a descriptive, extra-long option and ty
61 matches
Mail list logo
