Hi,
Brandon Casey wrote:
> --- a/sequencer.c
> +++ b/sequencer.c
[...]
> @@ -1042,13 +1041,8 @@ static int ends_rfc2822_footer(struct strbuf *sb, int
> ignore_footer)
Git is checking if (sb->buf) ends with a "Signed-off-by:" style
line. If it doesn't, it will need to add an extra blank line
be
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 ArTeN
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 c
Jonathan Nieder 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)
>
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
Chris Rorvick 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", but with y
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.
Signed-o
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 su
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 cu
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).
T
Junio C Hamano 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 our end).
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
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
---
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
When pushing update an existing ref, we wouldn't even know if we are
fast-forwarding the ref on the other end if:
* we do not have the object currently at the tip of remote;
* the object currently at the tip of remote is not a committish; or
* the object we are pushing is not a committish.
In
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).
T
On Mon, Jan 21, 2013 at 5:40 PM, Jeff King 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 wrote:
>> > However, if instead of the rule being
>> > "blobs on the remote side cannot be replaced", if it becomes "the old
>> > valu
Jeff King 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 Sat, Jan 5, 2013 at 11:12 AM, Jeff King 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" name.
Duy Nguyen 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 s
On Tue, Jan 22, 2013 at 6:12 AM, Martin von Zweigbergk
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
> wrote:
>> We have two ways of dealing with empty pathspec:
>>
>>
On Tue, Jan 22, 2013 at 2:27 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy 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
On Tue, Jan 22, 2013 at 8:45 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Tue, Jan 22, 2013 at 6:15 AM, Jeff King 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
Duy Nguyen 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
because people ex
Duy Nguyen writes:
> On Tue, Jan 22, 2013 at 6:15 AM, Jeff King 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 ent
On Mon, Jan 21, 2013 at 7:00 PM, Matthieu Moy 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'.
>
> The inconsist
On Tue, Jan 22, 2013 at 6:15 AM, Jeff King 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, should we
Thomas Ackermann writes:
> Signed-off-by: Thomas Ackermann
> ---
>
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 list: send the line "unsubscrib
On Mon, Jan 21, 2013 at 03:32:29PM -0800, Junio C Hamano wrote:
> "Jean-Noël AVILA" 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
Thomas Ackermann 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'.
>
> Signed-off-by: Thoma
Jeff King 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 new
> e
On Mon, Jan 21, 2013 at 03:33:46PM -0800, Junio C Hamano wrote:
> Jeff King 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.
> >
On Thu, Jan 17, 2013 at 09:18:50PM -0600, Chris Rorvick wrote:
> On Thu, Jan 17, 2013 at 7:06 PM, Jeff King 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
Jeff King 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
> doe
"Jean-Noël AVILA" 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".
Does the f
Matthieu Moy writes:
> Junio C Hamano 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
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 &&
> + S_ISREG(s
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 wrote:
> We have two ways of dealing with empty pathspec:
>
> 1. limit it to current prefix
> 2. match the entire working directory
>
> Some
On Sun, Jan 20, 2013 at 10:06:33AM -0800, Junio C Hamano wrote:
> Jeff King 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 in
On Sun, Jan 20, 2013 at 02:08:32PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >>> [uploadPack]
> >>> hiderefs = refs/changes
> >>
> >> Would you want to do the same thing on receive-pack? It could benefit
> >> from the same reduction in netwo
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
In test mode, git completion should only propose core commands.
Signed-off-by: Jean-Noel Avila
---
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".
contrib/completion/git-completion.bash |
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 t
"Philip Oakley" writes:
> From: "Joachim Schmitz"
> Sent: Monday, January 21, 2013 2:19 PM
>> Junio C Hamano wrote:
>>> Barry Wardell 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
>>>
From: "Joachim Schmitz"
Sent: Monday, January 21, 2013 2:19 PM
Junio C Hamano wrote:
Barry Wardell 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
threads:
http://thread.gmane.org/gmane.com
- 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 sho
Ralf Thielow 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-o
Junio C Hamano 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 by default,
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
---
2013/1/21 Th
Piotr Krukowiecki 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 option is chosen, the other on
Junio C Hamano 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 v1.5.2.5~1^ shows th
Junio C Hamano writes:
> Thomas Ackermann 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? T
Thomas Ackermann 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 seems to appea
On Mon, Jan 21, 2013 at 8:12 PM, Junio C Hamano wrote:
> Matthieu Moy 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
Please don't drop the Cc list!
"Brian J. Murrell" 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 fixed in Lustre
Nguyễn Thái Ngọc Duy 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" exists
Signed-off-by: Thomas Ackermann
---
Documentation/CodingGuidelines | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 5e60daf..4f40b44 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@
Ralf Thielow 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-o
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
---
Documentation/asciid
Matthieu Moy 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 add -u' and 'git a
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
On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano wrote:
> No. This is only about "git add -u", not any other forms of
> "git add ...with or without other args...".
>
> "git add -u" historically meant, and it still means, to
> "update the index with every change in the working tree", even when
> y
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 cons
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
---
po/de.po | 2
Junio C Hamano writes:
> Piotr Krukowiecki 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 -u", not any other forms of
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 th
Please ignore these series ... there are still problems with the size of the
patches :-|
- Original Nachricht
Von: Thomas Ackermann
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 'official' system na
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
---
Documentation/asciid
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 '
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...
http://www.giref.ulaval.ca/~ericc/strace-f_git_no_
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
wrote:
Good idea!
I did a strace and here i
Use one TAB for indentation and remove empty lines
Signed-off-by: Torsten Bögershausen
---
t/t0050-filesystem.sh | 48 +++-
1 file changed, 15 insertions(+), 33 deletions(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index a6fa3c5..05d
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
---
Changes
This test case has passed since this commit:
commit 0047dd2fd1fc1980913901c5fa098357482c2842
Author: Steffen Prohaska
Date: Thu May 15 07:19:54 2008 +0200
t0050: Fix merge test on case sensitive file systems
Remove the known breakage by using test_expect_success
Signed-off-by: Tors
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 http://vger.ke
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
---
On Mon, Jan 21, 2013 at 05:02:52PM +0100, Michael Haggerty wrote:
> Shouldn't "raw" be preceded with a colon like the other format specifi
Maxime Boissonneault 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 /proc/fs/lustre/version
lustre: 2.
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 writes:
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland
wrote:
Good idea
Erik Faye-Lund writes:
> On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland
> 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 chil
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
> ---
> Documentation/git-for-each-ref.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 de
Robin Rosenberg 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
> git add -u
That
- 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 'gi
Junio C Hamano wrote:
Barry Wardell 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.
- Fixed problems with git svn
John Keeping :
> > 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 shipped.
>
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
---
Documentation/git-for-each-ref.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-for-each-ref.txt
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland
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, but instead having
their s
On Mon, Jan 21, 2013 at 07:43:40AM -0500, Eric S. Raymond wrote:
> John Keeping :
>> 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 inherit
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/grep.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/grep.c b/builtin/grep.c
index 0e1b6c8..8025964 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -823,6 +823,8 @@ int cmd_grep(int argc, const char **argv, const char
*prefix)
:/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" exists and "git log :/abc" will gladly
take ":/abc" a
John Keeping :
> 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 correct) behavior
On Mon, Jan 21, 2013 at 06:28:53AM -0500, Eric S. Raymond wrote:
> John Keeping :
>> 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 think we ca
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 -u' and 'git add -A' are particularly
problema
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Changes: do not lose worktree's executable permission.
t/t1011-read-tree-sparse-checkout.sh | 3 ++-
t/t2021-checkout-overwrite.sh| 18 ++
unpack-trees.c | 31 +++
3 files changed
John Keeping :
> 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 branch, the start
On 01/20/2013 03:05 PM, Stephen Kelly wrote:
> I find the fixup command during an interactive rebase useful.
>
> Sometimes when cleaning up a branch, I end up in a situation like this:
>
> pick 07bc3c9 Good commit.
> pick 1313a5e Commit to fixup into c2f62a3.
> pick c2f62a3 Another commit.
>
On Sun, Jan 20, 2013 at 06:20:08PM -0500, Eric S. Raymond wrote:
> John Keeping :
>> 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 solve this
>
Piotr Krukowiecki 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 -u", not any other forms of
"git add ...with or without other
Junio C Hamano writes:
> Matthieu Moy 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 the change
>
> Did we ever agree
There are two implementations of append_signoff in log-tree.c and
sequencer.c, which do more or less the same thing. Unify on top of the
sequencer.c implementation.
Add a test in t4014 to demonstrate support for non-s-o-b elements in the
commit footer provided by sequence.c:append_sob. Mark test
From: Nguyễn Thái Ngọc Duy
This is a preparation step for merging with append_signoff from
sequencer.c
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Brandon Casey
---
builtin/log.c | 13 +
log-tree.c| 14 ++
revision.h| 2 +-
3 files changed, 12 insertion
1 - 100 of 114 matches
Mail list logo
