On Sun, Jan 20, 2013 at 7:53 PM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Implementing git rm -u as a tree-wide command would create a
discrepancy with git add -u. Implementing it as a current directory
command would make the migration harder
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
- The tortoisemerge mergetool does not work with filenames which
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
- The tortoisemerge mergetool does not work with filenames which
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
Do you mean git add will be disallowed without . or :/ argument?
Or will this change in future and git add without argument will me
whole tree, same as :/ ?
Let's talk conditional, not future, for now.
If the idea is to change the
Here's version 2 of the unify-appending-of-sob series. Hopefully this
addresses the comments made on the first series:
http://thread.gmane.org/gmane.comp.version-control.git/210390
The main difference is that the detection of the (cherry picked from ...)
line has been relaxed, and the
Commit c1e01b0c generalized the detection of the last paragraph
signed-off-by footer and used rfc2822 as a guideline. Support for rfc2822
style continuation lines was also implemented, but not correctly, so it has
never detected a line beginning with space or tab as a continuation of the
previous
The message part of test_commit() may not be appropriate for a tag name.
So let's allow test_commit to accept a fourth argument to specify the tag
name.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
t/test-lib-functions.sh | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff
Add some tests to ensure that 'cherry-pick -s' operates in the following
manner:
* Inserts a blank line before appending a s-o-b to a commit message that
does not contain a s-o-b footer
* Does not mistake first line subject: description as a s-o-b footer
* Does not mistake single
Junio C Hamano wrote:
Stephen Kelly steve...@gmail.com writes:
One scenario is something like this:
Start with a clean HEAD (always a good idea :) )
hack hack hack
make multiple commits
realize that a hunk you committed in an early patch belongs in a later
one. use git rebase -i to
When 'cherry-pick -s' is used to append a signed-off-by line to a cherry
picked commit, it does not currently detect the (cherry picked from...
that may have been appended by a previous 'cherry-pick -x' as part of the
s-o-b footer and it will insert a blank line before appending a new s-o-b.
Start treating the (cherry picked from line added by cherry-pick -x
the same way that the s-o-b lines are treated. Namely, separate them
from the main commit message body with an empty line.
Introduce tests to test this functionality.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
This is in preparation to unify the append_signoff implementations in
log-tree.c and sequencer.c.
Fixes test in t3511.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
builtin/commit.c | 2 +-
sequencer.c
Teach append_signoff to detect whether a blank line exists at the position
that the signed-off-by line will be added, and avoid adding an additional
one if one already exists. This is necessary to allow format-patch to add a
s-o-b to a patch with no commit message without adding an extra newline.
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
[bc: Squash the tests from Duy's original unify-appending-sob series.
Fix test 90 signoff: some random signoff-alike and mark as failing.
Correct behavior should insert a blank line after message body and
signed-off-by.
Add two
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
This is a preparation step for merging with append_signoff from
sequencer.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Brandon Casey bca...@nvidia.com
---
builtin/log.c | 13 +
log-tree.c| 14 ++
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
git add -u is one of the only exceptions (with git grep). I consider
this as a bug, and think this should be changed. This has been discussed
several times here, but no one took the time to actually do
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
Do you mean git add will be disallowed without . or :/ argument?
Or will this change in future and git add without argument will me
whole tree, same as :/ ?
No. This is only about git add -uRETURN, not any other forms of
git add ...with
On Sun, Jan 20, 2013 at 06:20:08PM -0500, Eric S. Raymond wrote:
John Keeping j...@keeping.me.uk:
I don't think there is any way to solve this without giving cvsps more
information, probably the last commit time for all git branches, but
perhaps I'm missing a fast-import feature that can help
John Keeping j...@keeping.me.uk:
But this is nothing more than a sticking plaster that happens to do
enough in this particular case
I'm beginning to think that's the best outcome we ever get in this
problem domain...
- if the Git repository happened to be on
a different
On Mon, Jan 21, 2013 at 06:28:53AM -0500, Eric S. Raymond wrote:
John Keeping j...@keeping.me.uk:
But this is nothing more than a sticking plaster that happens to do
enough in this particular case
I'm beginning to think that's the best outcome we ever get in this
problem domain...
I don't
John Keeping j...@keeping.me.uk:
I also disagree that cvsps outputs commits *newer* than T since it will
also output commits *at* T, which is what I changed with the patch in my
previous message.
Ah. OK, that is yet another bug inherited from 2.x - the code doesn't
match the documented (and
On Mon, Jan 21, 2013 at 07:43:40AM -0500, Eric S. Raymond wrote:
John Keeping j...@keeping.me.uk:
I also disagree that cvsps outputs commits *newer* than T since it will
also output commits *at* T, which is what I changed with the patch in my
previous message.
Ah. OK, that is yet another
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland
eric.chamberl...@giref.ulaval.ca wrote:
Good idea!
I did a strace and here is the output with the error:
http://www.giref.ulaval.ca/~ericc/strace_git_error.txt
Hope it will be insightful!
This trace doesn't seem to contain child-processes,
Commit 7dff9b3 (Support 'raw' date format) added a raw date format.
Update the git-for-each-ref documentation to include this.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/git-for-each-ref.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
John Keeping j...@keeping.me.uk:
Ah. OK, that is yet another bug inherited from 2.x - the code doesn't
match the documented (and correct) behavior. Please send me a patch
against the cvsps repo, I'll merge it.
Should now be in your inbox.
Received, merged, tested, and cvsps-3.10 has
Junio C Hamano wrote:
Barry Wardell barry.ward...@gmail.com writes:
These patches fix a bug which prevented git-svn from working with
repositories which use gitdir links.
Changes since v2:
- Rebased onto latest master.
- Added test case which verifies that the problem has been fixed.
-
- Ursprungligt meddelande -
Most git commands that can be used with our without a filepattern are
tree-wide by default, the filepattern being used to restrict their
scope.
A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git
add -A'.
The inconsistancy of 'git add
Robin Rosenberg robin.rosenb...@dewire.com writes:
git add -u without filepattern is, I believe very common, so no noisy
output there please.
What are you exactly suggesting? That we keep the inconsistant semantics
of git add -u or git add -A? Or another migration plan?
git diff
#looks good
On 01/21/2013 02:53 PM, John Keeping wrote:
Commit 7dff9b3 (Support 'raw' date format) added a raw date format.
Update the git-for-each-ref documentation to include this.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/git-for-each-ref.txt | 2 +-
1 file changed, 1
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland
eric.chamberl...@giref.ulaval.ca wrote:
Good idea!
I did a strace and here is the output with the error:
http://www.giref.ulaval.ca/~ericc/strace_git_error.txt
Hope it will be insightful!
This
Hi Thomas,
Can you tell me what is the version of the lustre servers and the lustre
clients ?
Thanks,
Maxime Boissonneault
HPC specialist @ Calcul Québec.
Le 2013-01-21 11:11, Thomas Rast a écrit :
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jan 18, 2013 at 6:50 PM, Eric
Maxime Boissonneault maxime.boissonnea...@calculquebec.ca writes:
Hi Thomas,
Can you tell me what is the version of the lustre servers and the
lustre clients ?
$ uname -a
Linux brutus4.ethz.ch 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
$ cat
Commit 7dff9b3 (Support 'raw' date format) added a raw date format.
Update the git-for-each-ref documentation to include this.
Signed-off-by: John Keeping j...@keeping.me.uk
---
On Mon, Jan 21, 2013 at 05:02:52PM +0100, Michael Haggerty wrote:
Shouldn't raw be preceded with a colon like the
Sorry for completely messing up the sensitvie/insensiteve
Please discard my patch from pu, I'll send v2.
Sorry for the confusion
/Torsten
--
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
The test case add (with different case) indicates a
known breakage when run on a case insensitive file system.
The test is invalid for case sensitive file system, it will always fail.
Check the precondition CASE_INSENSITIVE_FS before running it.
Signed-off-by: Torsten Bögershausen tbo...@web.de
Use one TAB for indentation and remove empty lines
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t0050-filesystem.sh | 48 +++-
1 file changed, 15 insertions(+), 33 deletions(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
Hi,
It just happened again. Now I have the strace -f output gzipped here:
http://www.giref.ulaval.ca/~ericc/strace-f_git_error.txt.gz
thanks,
Eric
On 01/21/2013 08:29 AM, Erik Faye-Lund wrote:
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland
eric.chamberl...@giref.ulaval.ca wrote:
Good
On 01/21/2013 12:07 PM, Eric Chamberland wrote:
Hi,
It just happened again. Now I have the strace -f output gzipped here:
http://www.giref.ulaval.ca/~ericc/strace-f_git_error.txt.gz
I added the strace -f output when non error occurs...
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line).
Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the
Git system. So change every occurrence of 'GIT and
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line). So change every occurrence
of 'GIT in the documention to 'Git'.
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Please ignore these series ... there are still problems with the size of the
patches :-|
- Original Nachricht
Von: Thomas Ackermann th.ac...@arcor.de
An: gits...@pobox.com, th.ac...@arcor.de
Datum: 21.01.2013 19:36
Betreff: [PATCH v2 0/6] GIT, Git, git
Git changed its
On 13-01-21 11:11 AM, Thomas Rast wrote:
What's odd is that while I cannot reproduce the original problem, there
seems to be another issue/bug with utime():
I wonder if this is related to http://jira.whamcloud.com/browse/LU-305.
That was reported as fixed in Lustre 2.0.0 and 2.1.0 but I
Junio C Hamano gits...@pobox.com writes:
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
Do you mean git add will be disallowed without . or :/ argument?
Or will this change in future and git add without argument will me
whole tree, same as :/ ?
No. This is only about git add
This fixes some minor issues and improves the
German translation a bit. The following things
were changed:
- use complete sentences in option related messages
- translate use consistently as verwendet
- don't translate make sense as macht Sinn
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
On 01/21/2013 12:05 PM, Michael Haggerty wrote:
It is perverse to have to turn a well-defined and manifestly
conflict-free wish into one that has a good chance of conflicting, just
because of a limitation of the tool.
Yes, I agree.
I would prefer to be able to mark a commit as 'should be
On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano gits...@pobox.com wrote:
No. This is only about git add -uRETURN, not any other forms of
git add ...with or without other args
git add -uRETURN historically meant, and it still means, to
update the index with every change in the working
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line).
Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the
Git system. So change every occurrence of 'GIT and
Matthieu Moy matthieu@imag.fr writes:
Most git commands that can be used with our without a filepattern are
tree-wide by default, the filepattern being used to restrict their scope.
A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
The inconsistancy of 'git
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line). So change every occurrence
of 'GIT in the documention to 'Git'.
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Ralf Thielow ralf.thie...@gmail.com writes:
This fixes some minor issues and improves the
German translation a bit. The following things
were changed:
- use complete sentences in option related messages
- translate use consistently as verwendet
- don't translate make sense as macht Sinn
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/CodingGuidelines | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 5e60daf..4f40b44 100644
--- a/Documentation/CodingGuidelines
+++
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
:/abc may mean two things:
- as a revision, it means the revision that has abc in commit
message.
- as a pathpec, it means abc from root.
Currently we see :/abc as a rev (most of the time), but never see it
as a pathspec even if abc
Please don't drop the Cc list!
Brian J. Murrell br...@interlinx.bc.ca writes:
What's odd is that while I cannot reproduce the original problem, there
seems to be another issue/bug with utime():
I wonder if this is related to http://jira.whamcloud.com/browse/LU-305.
That was reported as
On Mon, Jan 21, 2013 at 8:12 PM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@imag.fr writes:
Most git commands that can be used with our without a filepattern are
tree-wide by default, the filepattern being used to restrict their scope.
A few exceptions are: 'git grep',
Thomas Ackermann th.ac...@arcor.de writes:
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line).
Didn't I already say that we never changed the name? The same
description
Junio C Hamano gits...@pobox.com writes:
Thomas Ackermann th.ac...@arcor.de writes:
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line).
Didn't I already say that we
Junio C Hamano gits...@pobox.com writes:
But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,
2007-08-16) changed the semantics to limit the operation to the
working tree.
Not really. It fixed git add -u path, not plain git add -u. A quick
test checking out and compiling
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
Another issue is usability. Can we definitely say which is better: add
all changes from current subdir, or add all changes from whole tree? I
don't know.
Hard to tell, depending on users, use-case, ...
But the good news is: whatever
This fixes some minor issues and improves the
German translation a bit. The following things
were changed:
- use complete sentences in option related messages
- translate use consistently as verwendet
- don't translate make sense as macht Sinn
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
Junio C Hamano gits...@pobox.com writes:
Wouldn't we achieve the same consistency across modes of
add if we made them relative to the current directory?
As other people already said, it would be nice to have consistency
accross most if not all commands. AFAICT, the only exceptions to
tree-wide
- Ursprungligt meddelande -
git diff
#looks good
git add -u
That's indeed the kind of mistake I'd like to avoid. In your example,
git diff is tree-wide, and git add -u is limited to ., so in
general
git add -u won't stage the same thing as git diff just showed.
Good point.
From: Joachim Schmitz j...@schmitz-digital.de
Sent: Monday, January 21, 2013 2:19 PM
Junio C Hamano wrote:
Barry Wardell barry.ward...@gmail.com writes:
[...]
Thanks for your persistence ;-) As this is a pretty old topic, I'll
give two URLs for people who are interested to view the previous
Philip Oakley philipoak...@iee.org writes:
From: Joachim Schmitz j...@schmitz-digital.de
Sent: Monday, January 21, 2013 2:19 PM
Junio C Hamano wrote:
Barry Wardell barry.ward...@gmail.com writes:
[...]
Thanks for your persistence ;-) As this is a pretty old topic, I'll
give two URLs for
Hi,
Matthieu Moy wrote:
The inconsistancy of 'git add -u' and 'git add -A' are particularly
problematic since other 'git add' subcommands (namely 'git add -p' and
'git add -e') are tree-wide by default.
Flipping the default now is unacceptable, so this patch starts training
users to type
In test mode, git completion should only propose core commands.
Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---
I reworked the patch so that the test argument is only evaluated
when sourcing the file and there is no environment clutter.
At least, it works for me.
On Sat, Jan 19, 2013 at 11:16:00AM -0800, Junio C Hamano wrote:
For example, if you mirror-clone from either of my repositories from
GitHub:
git clone --mirror git://github.com/git/git/
git clone --mirror git://github.com/gitster/git/
you will see stuff that does not belong to
On Sun, Jan 20, 2013 at 02:08:32PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
[uploadPack]
hiderefs = refs/changes
Would you want to do the same thing on receive-pack? It could benefit
from the same reduction
On Sun, Jan 20, 2013 at 10:06:33AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
[uploadPack]
hiderefs = refs/changes
Would you want to do the same thing on receive-pack? It could benefit
from the same reduction in network cost (although it tends to be
Hi,
I was tempted to ask this before, and the recent thread regarding add
-u/A [1] convinced me to.
On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
We have two ways of dealing with empty pathspec:
1. limit it to current prefix
2. match the entire working
On Mon, Jan 21, 2013 at 06:40:33PM +0700, Nguyen Thai Ngoc Duy wrote:
+ /*
+ * If it has the same content that we are going to overwrite,
+ * there's no point in complaining. We still overwrite it in
+ * the end though.
+ */
+ if (ce
+
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,
2007-08-16) changed the semantics to limit the operation to the
working tree.
Not really. It fixed git add -u path, not plain git add
Jean-Noël AVILA jn.av...@free.fr writes:
At least, it works for me.
I suspect that your approach will still not fix the case in which
you build a branch with a new command git-check-ignore, and then
check out another branch that does not yet have that command without
first running make clean.
Jeff King p...@peff.net writes:
It may even make sense to have git push honor it, excluding them
from git push --mirror (or git push --all if some of the
branches are hidden); I haven't thought things through, though.
That is harder, as that is something that happens on the client. How
does
Jeff King p...@peff.net writes:
... The problem there is not already exists but rather
a blob is not something that can fast-forward. Using the existing
REJECT_NONFASTFORWARD is insufficient (because later code will recommend
pull-then-push, which is wrong). So I'd be in favor of creating a
Thomas Ackermann th.ac...@arcor.de writes:
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line). So change every occurrence
of 'GIT in the documention to 'Git'.
Thomas Ackermann th.ac...@arcor.de writes:
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Forgot --stat?
It helps to check the integrity of patch application and also helps
anticipating possible interaction with other topics in flight.
Please don't omit it.
--
To unsubscribe from this
On Tue, Jan 22, 2013 at 6:15 AM, Jeff King p...@peff.net wrote:
Can you elaborate on when this code is triggered?
In the general case, shouldn't we already know the sha1 of what's on
disk in the index, and be able to just compare the hashes? And if we
don't, because the entry is start-dirty,
On Mon, Jan 21, 2013 at 7:00 PM, Matthieu Moy matthieu@imag.fr wrote:
Most git commands that can be used with our without a filepattern are
tree-wide by default, the filepattern being used to restrict their scope.
A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
Duy Nguyen pclo...@gmail.com writes:
On Tue, Jan 22, 2013 at 6:15 AM, Jeff King p...@peff.net wrote:
Can you elaborate on when this code is triggered?
In the general case, shouldn't we already know the sha1 of what's on
disk in the index, and be able to just compare the hashes? And if we
Duy Nguyen pclo...@gmail.com writes:
What about 'grep' and 'clean'? I think at least 'clean' should go
tree-wide default too. I don't mind grep go the same way either but I
think people voiced preference in current behavior..
I think the major argument for git grep to be the way it is is
On Tue, Jan 22, 2013 at 8:45 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Jan 22, 2013 at 6:15 AM, Jeff King p...@peff.net wrote:
Can you elaborate on when this code is triggered?
In the general case, shouldn't we already know the sha1 of what's on
On Tue, Jan 22, 2013 at 6:12 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
Hi,
I was tempted to ask this before, and the recent thread regarding add
-u/A [1] convinced me to.
On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com
wrote:
We have two ways of dealing
Duy Nguyen pclo...@gmail.com writes:
... take :/abc as rev even it's ambiguous. This patch makes it:
- ambiguous when abc exists on worktree
- a rev if abc does not exist on worktree
- a path if abc is not found in any commits (although better use
The any commits above sounds very scary.
On Sat, Jan 5, 2013 at 11:12 AM, Jeff King p...@peff.net wrote:
On Mon, Dec 31, 2012 at 03:30:53AM -0700, Martin Fick wrote:
The general approach is to setup a transaction and either
commit or abort it. A transaction can be setup by renaming
an appropriately setup directory to the ref.lock
Jeff King p...@peff.net writes:
I really hate to suggest this, but should it be more like:
if test -z $FAKE_COMMAND_LIST; then
__git_cmdlist() {
git help -a | egrep '^ [a-zA-Z0-9]'
}
else
__git_cmdlist() {
printf '%s'
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 the
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 suggesting to fetch and integrate before pushing
again does not make sense).
The nonfastforward field is only used to decide what value to
assign to the status locally in a single function. Remove it from
the struct ref and make it into a local variable.
The requires_force field is not used to decide if the proposed
update requires a --force option to succeed, or to
The update field in struct ref is only used in a very narrow
scope in a single function. Remove it.
Also simplify the code that rejects an attempted push by first
checking if the proposed update is forced (in which case we do not
need any check on our end).
Signed-off-by: Junio C Hamano
This one has a logic flaw. The logic outlined in the cover letter
is correct, and the one described in the log message of this one is
not.
We should say fetch first only when we do not have old_sha1.
diff --git a/remote.c b/remote.c
index 248910f..8c39ea2 100644
--- a/remote.c
+++ b/remote.c
Junio C Hamano gits...@pobox.com writes:
The update field in struct ref is only used in a very narrow
scope in a single function. Remove it.
Also simplify the code that rejects an attempted push by first
checking if the proposed update is forced (in which case we do not
need any check on
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 suggesting to fetch and integrate before pushing
again does not make sense).
The nonfastforward and update fields are only used while
deciding what value to assign to the status locally in a single
function. Remove them from the struct ref.
The requires_force field is not used to decide if the proposed
update requires a --force option to succeed, or to record such a
When we push to update an existing ref, if:
* we do not have the object at the tip of the remote; or
* the object at the tip of the remote is not a commit; or
* the object we are pushing is not a commit,
there is no point suggesting to fetch, integrate and push again.
If we do not have the
Instead of using deeply nested if/else statements, first decide what
rejection status we would get if this push weren't forced, and then
assign the rejection reason to the ref-status field and flip the
ref-forced_update field when we forced a push for a ref that indeed
required forcing.
Chris Rorvick ch...@rorvick.com writes:
I agree with everything above. I just don't understand why reverting
the already exists behavior for non-commit-ish objects was a
prerequisite to fixing this.
Because it is a regression. People who did not force such a push
did not get already exists,
As far as I am concerned, I am pretty much done with this topic, at
least for now. Of course if there are bugreports I'll try to help
resolving them, but I do not expect myself adding new object-type
based policy decision to this codepath.
The call the updated call makes to ref_newer() no longer
Jonathan Nieder jrnie...@gmail.com writes:
Would it be possible to make this conditional on cwd not being at the
toplevel (the case where git add -u :/ and git add -u . have
different behavior)? E.g.,
static const char *here[2] = { ., NULL };
if (prefix)
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Other implementations, eg. Git in cygwin are allegedly also
somewhat incompatible with Git For Windows and on *nix platforms
the resolution of the timestamps may differ.
Any stat checking by git will then need to check
Die Marke [url=http://www.taschenoutlet.eu/]Mulberry taschen outlet[/url]
bietet hq taschen insbesondere innerhalb der Kleinen Gemeinde Chilcompton
auf Großbritannien. Die Longchamp bestimmte Marke macht Viel Bessere nutzung
von Komponenten und weiblich Baio echte bei der entwicklung of this
1 - 100 of 101 matches
Mail list logo