Official support for specifying --work-tree/GIT_WORK_TREE without
--git-dir/GIT_DIR was added with v1.7.4-rc3~2^2~2. Update description
of GIT_WORK_TREE to reflect this.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Commit ea472c1 made most of the relevant updates. Noticed this while
On Wed, Jan 23, 2013 at 3:55 PM, Junio C Hamano gits...@pobox.com wrote:
This builds on Chris Rorvick's earlier effort to forbid unforced
updates to refs/tags/ hierarchy and giving sensible error and advise
messages for that case (we are not rejecting such a push due to fast
forwardness, and
On Wed, Jan 23, 2013 at 3:12 PM, John Keeping j...@keeping.me.uk wrote:
The existing script (git-cvsimport.perl) won't ever work with cvsps-3
since features it relies on have been removed.
Not reporting the ancestry branch seems to be the big one. Are there
others? I had a version of the Perl
On Thu, Jan 24, 2013 at 11:04 PM, Junio C Hamano gits...@pobox.com wrote:
Would it be sufficient to do this? I think the tag already exists
in the remote is already clear that we are talking about the
destination.
Good point.
diff --git a/builtin/push.c b/builtin/push.c
index
On Wed, Jan 23, 2013 at 3:28 AM, John Keeping j...@keeping.me.uk wrote:
In my opinion the incremental import support really is substantially
worse in cvsimport-3 than cvsimport-2. cvsimport-2 looks at the output
of git-for-each-ref to calculate the dates from which to continue each
branch.
On Mon, Jan 21, 2013 at 5:40 PM, Jeff King p...@peff.net wrote:
On Thu, Jan 17, 2013 at 09:18:50PM -0600, Chris Rorvick wrote:
On Thu, Jan 17, 2013 at 7:06 PM, Jeff King p...@peff.net wrote:
However, if instead of the rule being
blobs on the remote side cannot be replaced, if it becomes
On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk wrote:
Hi Chris,
On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15
tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent
On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk wrote:
On Thu, Jan 10, 2013 at 10:27:16PM -0600
On Sun, Jan 20, 2013 at 1:24 PM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jan 20, 2013 at 10:57:50AM -0800, Junio C Hamano wrote:
This is not a noise, though.
Chris, how would we want to proceed? I'd prefer at some point to
see cvsimport-3 to be in sync when the one patched and tested
On Sun, Jan 20, 2013 at 2:17 PM, Chris Rorvick ch...@rorvick.com wrote:
On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
On Sun, Jan 20, 2013 at 6:58 AM, John
On Thu, Jan 17, 2013 at 12:59 AM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote:
It is fine when pushing into refs/tags/ hierarchy. It is *NOT*
OK if the type check does not satisfy
On Thu, Jan 17, 2013 at 7:06 PM, Jeff King p...@peff.net wrote:
However, if instead of the rule being
blobs on the remote side cannot be replaced, if it becomes the old
value on the remote side must be referenced by what we replace it with,
that _is_ something we can calculate reliably on the
On Wed, Jan 16, 2013 at 11:43 AM, Jeff King p...@peff.net wrote:
I think that is a reasonable rule that could be applied across all parts
of the namespace hierarchy. And it could be applied by the client,
because all you need to know is whether ref-old_sha1 is reachable from
ref-new_sha1.
On Wed, Jan 16, 2013 at 9:11 PM, Jeff King p...@peff.net wrote:
is_forwardable() did solve a UI issue. Previously all instances where
old is not reachable by new were assumed to be addressable with a
merge. is_forwardable() attempted to determine if the concept of
forwarding made sense given
On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote:
It is fine when pushing into refs/tags/ hierarchy. It is *NOT*
OK if the type check does not satisfy this function. In that case,
we do not actually see the existence of the destination as a
problem, but it is reported
On Tue, Jan 15, 2013 at 5:10 PM, Ben Walton bdwal...@gmail.com wrote:
Neither %s or %z are portable strftime format specifiers. There is no
need for %s in git-cvsimport as the supplied time is already in
seconds since the epoch. For %z, use the function get_tz_offset
provided by Git.pm
On Mon, Jan 14, 2013 at 9:02 PM, Junio C Hamano gits...@pobox.com wrote:
I converted one of Chris's follow-up test tweaks to this to
illustrate how it can be done without breaking tests for the
original cvsimport, but didn't do all of them. Chris, is this a
foundation we can work together on
On Sun, Jan 13, 2013 at 7:40 PM, Junio C Hamano gits...@pobox.com wrote:
The new cvsps 3.x series lacks support of some options cvsps 2.x
series had and used by cvsimport-2; add a replacement program from
the author of cvsps 3.x and allow users to choose it by setting the
GIT_CVSPS_VERSION
This is seen in cvsps versions 2.x and up through at least 3.7.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Ran into this recently. No branching and no criss cross timestamps,
just lazy commit messages. And it magically backed out a bug fix.
This applies on top of master. With minor
This is seen in cvsps versions 2.x and up through at least 3.7.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
It actually does fail without the false at the end. :-P Sorry for
the noise.
t/t9605-cvsimport-commit-order.sh | 24 +++
t/t9605/cvsroot/.gitattributes | 1 +
t
On Fri, Jan 11, 2013 at 11:38 PM, Junio C Hamano gits...@pobox.com wrote:
By the way, Chris, we'll need your Sign-off on the three paches
(t/lib-cvs.sh fix to allow cvsps v3, t9600 fix and t9604 fix).
Sure. I was just maintaining them for myself but thought I'd share
when I saw the
Reroll w/ sign-off.
Chris Rorvick (3):
t/lib-cvs.sh: allow cvsps version 3.x.
t9600: fixup for new cvsimport
t9604: fixup for new cvsimport
t/lib-cvs.sh| 2 +-
t/t9600-cvsimport.sh| 10 --
t/t9604-cvsimport-timestamps.sh | 5 ++---
3 files changed
cvsimport no longer supports -a (import all commits including recent ones)
and no longer uses the 'origin' branch by default for imports.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
t/t9600-cvsimport.sh | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/t/t9600
cvsps no longer writes a cache file and therefore no longer can be told
to ignore it with -x.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
t/t9604-cvsimport-timestamps.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604
On Sat, Jan 12, 2013 at 12:36 AM, Junio C Hamano gits...@pobox.com wrote:
I too noticed the droppage of -a support, which may not be a big
deal (people can drop it from their script, run cvsimport and they
can drop newer commits from the resulting Git history to emulate the
old behaviour
of the t9604 tests pass.
Chris
Chris Rorvick (3):
t/lib-cvs.sh: allow cvsps version 3.x.
t9600: fixup for new cvsimport
t9604: fixup for new cvsimport
t/lib-cvs.sh| 2 +-
t/t9600-cvsimport.sh| 10 --
t/t9604-cvsimport-timestamps.sh | 5 ++---
3
---
t/t9600-cvsimport.sh | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 4c384ff..14f54d5 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -44,7 +44,7 @@ EOF
test_expect_success PERL 'import a
---
t/t9604-cvsimport-timestamps.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604-cvsimport-timestamps.sh
index 1fd5142..b1629b6 100755
--- a/t/t9604-cvsimport-timestamps.sh
+++ b/t/t9604-cvsimport-timestamps.sh
@@ -7,8 +7,7 @@
On Sun, Jan 6, 2013 at 8:23 PM, 乙酸鋰 ch3co...@gmail.com wrote:
about git 1.8.2
* git push now requires -f to update a tag, even if it is a
fast-forward, as tags are meant to be fixed points.
Does the server side validate this? Do we need to upgrade git on
server side to support this?
On Tue, Jan 1, 2013 at 11:26 AM, Eric S. Raymond e...@thyrsus.com wrote:
diff --git a/git-cvsimport.py b/git-cvsimport.py
new file mode 100755
index 000..6407e8a
--- /dev/null
+++ b/git-cvsimport.py
@@ -0,0 +1,342 @@
+#!/usr/bin/env python
+#
+# Import CVS history into git
+#
+#
from cvsps will
have on incremental imports. Is there any?
Thanks,
Chris Rorvick
--
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
On Mon, Dec 17, 2012 at 2:20 AM, Johannes Sixt j.s...@viscovery.net wrote:
+'git checkout' [--detach] [commit]::
The title here is better spelled as two lines:
'git checkout' commit::
'git checkout' --detach branch::
AsciiDoc renders these horizontally separated by a comma when
formatted as
On Mon, Dec 17, 2012 at 7:53 PM, Junio C Hamano gits...@pobox.com wrote:
Here is a work-in-progress relative to Chris's 83c9989
(Documentation/git-checkout.txt: document 70c9ac2 behavior,
2012-12-17).
It sounds pretty good to me.
@@ -54,12 +61,17 @@ $ git checkout branch
that is to say,
On Sun, Dec 16, 2012 at 11:52 PM, Andrew Ardill andrew.ard...@gmail.com wrote:
This is true, but I don't think it is documented.
I noticed this, too. I was just about to send a patch to add this.
Chris
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
This is response to the questions posed in:
http://thread.gmane.org/gmane.comp.version-control.git/211624
It doesn't seem like the behavior implemented in 70c9ac2 is documented.
Chris Rorvick (2):
Documentation/git-checkout.txt: clarify usage
Documentation/git-checkout.txt: document
The forms of checkout that do not take a path are lumped together in the
DESCRIPTION section, but the description for this group is dominated by
explanation of the -b|-B form. Split these apart for more clarity.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-checkout.txt
Document the behavior implemented in 70c9ac2 (DWIM git checkout
frotz to git checkout -b frotz origin/frotz).
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-checkout.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/git-checkout.txt b
On Fri, Dec 7, 2012 at 6:50 PM, Matthew Ciancio
matthew.cianci...@gmail.com wrote:
Imagine this scenario:
1) You have a Git repo with two branches (branchA and branchB), which are
currently identical.
2) Checkout to branch.
3) Create file foo.txt, stage it and commit it.
4) Create file
On Sat, Dec 8, 2012 at 6:06 PM, Matthew Ciancio
matthew.cianci...@gmail.com wrote:
Hi Chris,
Yes, I don't think I have explained myself well enough.
When I say disappear I do not mean get deleted, I mean: go out of view
just like foo.txt does, as it is committed to branchB and not merged
The sentence originally began Note that ... and was changed to
NOTE: ... This change should have been made at the same time.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
This applies to the current cr/push-force-tag-update branch. It can
probably just be folded into the last commit
Added a new config option to turn off the already-exists advice. We
also want to observe the 'pushNonFastForward' setting, but the name of
this config is too narrow after this addition. Renamed to have broader
scope while retaining the old name as an alias for backward-
compatibility.
Chris
The 'pushNonFastForward' advice config can be used to squelch several
instances of push-related advice. Rename it to 'pushUpdateRejected' to
cover other reject scenarios that are unrelated to fast-forwarding.
Retain the old name for compatibility.
Signed-off-by: Chris Rorvick ch...@rorvick.com
Add 'advice.pushAlreadyExists' option to disable the advice shown when
an update is rejected for a reference that is not allowed to update at
all (verses those that are allowed to fast-forward.)
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/config.txt | 8 ++--
advice.c
that can go
unnoticed if fast-forwarding is allowed.
Chris Rorvick (8):
push: return reject reasons as a bitset
push: add advice for rejected tag reference
push: flag updates
push: flag updates that require force
push: require force for refs under refs/tags/
push: require force
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 13 -
builtin/send-pack.c | 4 ++--
transport.c | 17
Advising the user to fetch and merge only makes sense if the rejected
reference is a branch. If none of the rejections are for branches, just
tell the user the reference already exists.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 11 +++
cache.h| 1
If the reference exists on the remote and it is not being removed, then
mark as an update. This is in preparation for handling tags (lightweight
and annotated) exceptionally.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
cache.h | 1 +
remote.c | 18 +++---
2 files changed
/ should be rejected unless the update is
forced.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 11 ++-
builtin/push.c | 2 +-
builtin/send-pack.c| 5 +
cache.h| 1 +
remote.c | 18
Add a flag for indicating an update to a reference requires force.
Currently the `nonfastforward` flag is used for this when generating the
status message. A separate flag insulates dependent logic from the
details of set_ref_status_for_push().
Signed-off-by: Chris Rorvick ch...@rorvick.com
in write_ref_sha1(). Thus
someone fast-forwarding to a tag is probably not doing so by accident.
Since updating to a tag is benign and unlikely to cause confusion, allow
it in case someone finds the behavior useful.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
remote.c | 5 +
1 file changed
Rewrite to remove inter-dependencies amongst the rules.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
remote.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/remote.c b/remote.c
index ee0c1e5..6309a87 100644
--- a/remote.c
+++ b
-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 10 +-
remote.c | 11 +--
t/t5516-fetch-push.sh | 21 +
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
On Mon, Nov 26, 2012 at 12:43 PM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick ch
On Mon, Nov 26, 2012 at 12:53 PM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
Pushes must already (by default) update to a commit-ish due the fast-
forward check in set_ref_status_for_push(). But rejecting for not being
a fast-forward suggests
On Mon, Nov 26, 2012 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
diff --git a/remote.c b/remote.c
index 4a6f822..012b52f 100644
--- a/remote.c
+++ b/remote.c
@@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref
*remote_refs, int
:
http://thread.gmane.org/gmane.comp.version-control.git/208354
This series prevents fast-forwards if the reference is under the
refs/tags/* hierarchy or if the old object is a tag.
Chris Rorvick (7):
push: return reject reasons via a mask
push: add advice for rejected tag reference
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 13 -
builtin/send-pack.c | 4 ++--
transport.c | 17
Advising the user to fetch and merge only makes sense if the rejected
reference is a branch. If none of the rejections are for branches, just
tell the user the reference already exists.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 11 +++
cache.h| 1
If the reference exists on the remote and the update is not a delete,
then mark as an update. This is in preparation for handling tags and
branches differently when pushing.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
cache.h | 1 +
remote.c | 18 +++---
2 files changed, 12
Add a flag for indicating an update to a reference requires force.
Currently the nonfastforward flag of a ref is used for this when
generating status the status message. A separate flag insulates the
status logic from the details of set_ref_status_for_push().
Signed-off-by: Chris Rorvick ch
/ should be rejected unless the update is
forced.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 11 ++-
builtin/push.c | 2 +-
builtin/send-pack.c| 5 +
cache.h| 1 +
remote.c | 18
Do not allow fast-forwarding of references that point to a tag object.
This keeps the behavior consistent with lightweight tags. Additionally,
allowing the reference to update could leave the old object dangling.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 10
is presented with more appropriate advice.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
remote.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/remote.c b/remote.c
index f5bc4e7..ee0c1e5 100644
--- a/remote.c
+++ b/remote.c
@@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref
On Mon, Nov 19, 2012 at 2:23 PM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
The object referenced by src is used to update the dst reference
-on the remote side, but by default this is only allowed if the
-update can fast-forward dst. By having
cases. Do the annotated tests outside of refs/tags/
so that it actually tests different functionality.
Chris Rorvick (5):
push: return reject reasons via a mask
push: add advice for rejected tag reference
push: flag updates
push: flag updates that require force
push: update remote
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 13 -
builtin/send-pack.c | 4 ++--
transport.c | 17
Add a flag for indicating an update to a reference requires force.
Currently the nonfastforward flag of a ref is used for this when
generating status the status message. A separate flag insulates the
status logic from the details of set_ref_status_for_push().
Signed-off-by: Chris Rorvick ch
indicating the update is being rejected due to the reference
already existing in the remote. This can be overridden by passing
--force to git push.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 10 +-
builtin/push.c | 2 +-
builtin/send-pack.c
If the reference exists on the remote and the the update is not a
delete, then mark as an update. This is in preparation for handling
tags and branches differently when pushing.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
cache.h | 1 +
remote.c | 18 +++---
2 files changed
indicating the update is being rejected due to the reference
already existing in the remote. This can be overridden by passing
--force to git push.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Fix C99 comment.
Documentation/git-push.txt | 10 +-
builtin/push.c | 2
://github.com/peff/git.git
to pickup changes in nd/builtin-to-libgit.
Chris Rorvick (5):
push: return reject reasons via a mask
push: add advice for rejected tag reference
push: flag updates
push: flag updates that require force
push: update remote tags only with force
Documentation/git
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 13 -
builtin/send-pack.c | 4 ++--
transport.c | 17
Advising the user to fetch and merge only makes sense if the rejected
reference is a branch. If none of the rejections were for branches,
tell the user they need to force the update(s).
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 16 ++--
cache.h| 1
If the reference exists on the remote and the the update is not a
delete, then mark as an update. This is in preparation for handling
tags and branches differently when pushing.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
cache.h | 1 +
remote.c | 18 +++---
2 files changed
indicating the update is being rejected due to the reference
already existing in the remote. This can be overridden by passing
--force to git push.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 10 +-
builtin/push.c | 3 +--
builtin/send-pack.c
Add a flag for indicating an update to a reference requires force.
Currently the nonfastforward flag of a ref is used for this when
generating status the status message. A separate flag insulates the
status logic from the details of set_ref_status_for_push().
Signed-off-by: Chris Rorvick ch
On Fri, Nov 9, 2012 at 12:38 PM, Jeff King p...@peff.net wrote:
On Sun, Nov 04, 2012 at 09:08:23PM -0600, Chris Rorvick wrote:
Patch series to prevent push from updating remote tags w/o forcing them.
Split out original patch to ease review.
Chris Rorvick (5):
push: return reject reasons
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 13 -
transport.c| 17 -
transport.h|9
Advising the user to fetch and merge only makes sense if the rejected
reference is a branch. If none of the rejections were for branches,
tell the user they need to force the update(s).
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 16 ++--
cache.h
If the reference exists on the remote and the the update is not a
delete, then mark as an update. This is in preparation for handling
tags and branches differently when pushing.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
cache.h |1 +
remote.c | 19 ---
2 files
indicating the update is being rejected due to the reference
already existing in the remote. This can be overridden by passing
--force to git push.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 10 +-
builtin/push.c |3 +--
builtin/send
On Thu, Nov 1, 2012 at 1:40 PM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote:
Jeff King wrote:
What's cooking in git.git (Oct 2012, #09; Mon, 29)
--
[snip]
* cr/cvsimport-local-zone (2012-10-16) 1 commit
- git-cvsimport: allow
(oops, now my email was rejected)
On Wed, Oct 31, 2012 at 12:55 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi,
(again because the mailing list rejected it) (Gmal switched interface
and HTML is the default)
On Wed, Oct 31, 2012 at 6:37 AM, Chris Rorvick ch...@rorvick.com wrote
On Mon, Oct 29, 2012 at 4:35 PM, Jeff King p...@peff.net wrote:
On Mon, Oct 29, 2012 at 06:23:30PM +0100, Kacper Kornet wrote:
That patch just blocks non-forced updates to refs/tags/. I think a saner
start would be to disallow updating non-commit objects without a force.
We already do so
On Tue, Oct 30, 2012 at 1:34 PM, Angelo Borsotti
angelo.borso...@gmail.com wrote:
Hi Cris,
I think a key in the config file of the remote repo is better than an
option on git-push for what concerns security: it allows the owner of
the remote repo to enforce the policy not to overwrite tags,
update rejections are assumed to be for branches.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 10 +-
builtin/push.c | 12
builtin/send-pack.c| 6 ++
cache.h| 3 +++
remote.c
, which you can't reseat unless you use -f.
[1] By default, git fetch does not fetch tags that it already has.
Also, git checkout tag puts you on a detached HEAD. This seems
pretty significant with regard to Git respecting a tags don't move
convention.
Chris Rorvick
--
To unsubscribe from this list
On Sun, Oct 28, 2012 at 4:49 PM, Philip Oakley philipoak...@iee.org wrote:
From: Chris Rorvick ch...@rorvick.com Sent: Sunday, October 28, 2012
7:59 PM
On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt j...@kdbg.org wrote:
Tags are refs, just like branches. Tags don't move is just a
convention
On Fri, Oct 26, 2012 at 8:37 AM, Drew Northup n1xim.em...@gmail.com wrote:
(As for deleting the current branch, you can't really do that on a
proper bare remote anyway as there is no such thing as a current
branch in that context.)
Really? When I clone a bare repository I see a HEAD, and Git
.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Use System V timezones in unit test per feedback from Junio and Peff.
Also, use timestamps from before the 2007 changes to DST--seems
reasonable that people may not have bothered patching their systems for
this in some parts of the world
On Mon, Oct 15, 2012 at 12:40 PM, Junio C Hamano gits...@pobox.com wrote:
diff --git a/t/t9604-cvsimport-timestamps.sh
b/t/t9604-cvsimport-timestamps.sh
new file mode 100644
Huh? What happened to the executable bit we saw earlier?
Uh, yeah. Sorry about that.
+test_expect_success 'check
.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Cleaned up unit tests and added more detail to documentation.
Unit test is inherently platform dependent due to dependency on
zoneinfo database. Is there a way to improve this situation?
Documentation/git-cvsimport.txt| 8 +-
git
with the hardcoded TZ environment
setting. Also, the problem solved by the second patch could also be
addressed by simply removing the hardcoded TZ setting in favor of having
the user specify in their environment. Both of these solutions build on
the changes made in the first patch, though.
Chris
to the Git commit with local timezone
offset.)
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
git-cvsimport.perl |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 8032f23..2f5da9e 100755
--- a/git-cvsimport.perl
+++ b/git
doing the import is equivalent to the current
behavior. But since a new default may be an unwelcome surprise to
some, make this new behavior available as an option.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-cvsimport.txt | 13 ++---
git-cvsimport.perl
95 matches
Mail list logo
