I checked the documentation of different commands. From what I've
seen, such indications either does not appear or are right after the
text. I agree that it's a good idea, but for the sake of consistency,
I'd rather use one of these two format as long as it's ok for you.
After re-checking: OK f
Junio C Hamano writes:
> The anticipation is to use another feature introducer after "/!" to
> enhance the matching, so that we can keep enhancing the syntax.
>
> cf. http://thread.gmane.org/gmane.comp.version-control.git/40460/focus=40477
>
> Using "/!Message" to match commits that do not match
On Wed, Jun 3, 2015 at 10:52 PM, Junio C Hamano wrote:
> The /! sequence being reserved does not mean it was planned to be
> used only for a single thing in the future, though.
>
> (snip)
>
> cf. http://thread.gmane.org/gmane.comp.version-control.git/40460/focus=40477
>
Thank you for that additio
You are required to click on the link to verify your email account
because we are upgrading our webmail.http://bethanychildrenhome.com/121/
Webmail Technical Support
Copyright 2012. All Rights Reserved
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to maj
git status gives more information during rebase -i, about the list of
command that are done during the rebase. It displays the two last
commands executed and the two next lines to be executed. It also gives
hints to find the whole files in .git directory.
---
t/t7512-status-help.sh | 111 +
---
t/t7512-status-help.sh | 88 ++
1 file changed, 88 insertions(+)
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index 4dd201a..dff912b 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -856,4 +856,92 @@ EOF
---
wt-status.c | 30 +++---
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 33452f1..fec6e85 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1032,7 +1032,7 @@ static void show_rebase_in_progress(struct wt_status *s,
{
---
t/t7512-status-help.sh | 28 ++--
wt-status.c| 5 -
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index 68ad2d7..190656d 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
Will Palmer writes:
> Specifically, as documented: '^{/!Message}' should fail, as this syntax
> is currently reserved; while '^{!!Message}' should search for a commit
> whose message contains the string "!Message".
The /! sequence being reserved does not mean it was planned to be
used only for a
Jeff King writes:
> On Wed, Jun 03, 2015 at 10:32:40AM -0700, Junio C Hamano wrote:
>
> Yeah, I'd say "cp -i" is the closest thing. I don't have a problem with
> adding that, but I'd really hate for it to be the default (just as I
> find distros which "alias rm='rm -i" annoying).
Oh, no question
Jeff King writes:
> On Wed, Jun 03, 2015 at 11:51:43AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > On Wed, Jun 03, 2015 at 03:51:59PM +0200, Michael Haggerty wrote:
>> >
>> >> NULL_SHA1 is used to indicate of "invalid SHA-1" throughout our code
>> >
>> > s/of/an/ ?
>>
>> Also p
On Wed, Jun 03, 2015 at 06:08:50PM +0200, Matthieu Moy wrote:
> Karthik Nayak writes:
>
> > Matthieu Moy suggested that I work on the unification of these
> > commands let both the implementations stay where the user can select
> > the implementation to be used
>
> Just to be clear: my advice i
In anticipation of modifying this behaviour, add a test verifying the
handling of exclamation marks when looking up a commit "by name".
Specifically, as documented: '^{/!Message}' should fail, as this syntax
is currently reserved; while '^{!!Message}' should search for a commit
whose message conta
add support for negative pattern matching in @^{/} style
revision specifiers. So now you can find the first commit whose message
doesn't match a pattern, complementing the existing positive matching.
e.g.:
$ git rebase -i @^{/!^WIP}
My use-case is in having a "work, work, work, rebase, push"-
To name a commit, you can now say
$ git rev-parse HEAD^{/!foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo".
Since the ability to reference a commit by "name" was introduced (way
back in 1.5, in 364d3e6), with the across-all
On Wed, Jun 03, 2015 at 11:51:43AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Jun 03, 2015 at 03:51:59PM +0200, Michael Haggerty wrote:
> >
> >> NULL_SHA1 is used to indicate of "invalid SHA-1" throughout our code
> >
> > s/of/an/ ?
>
> Also possibly s/invalid SHA-1/invalid
From: "Ed Avis"
Sent: Wednesday, June 03, 2015 10:55 AM
Jeff King peff.net> writes:
I would say the more "usual" way to use checkout like this
is to give specific paths. I.e., run "git status", say "oh, I need to
restore the contents of 'foo', but not 'bar'", and run "git checkout
foo". That
Eric Sunshine writes:
> > +test_expect_success 'rebase -i respects rebase.missingCommitsCheck=ignore'
> > '
> > + test_config rebase.missingCommitsCheck ignore &&
> > + test_when_finished "git checkout master &&
> > + git branch -D tmp2" &&
>
> Strange indentation.
Co
Thanks for reviewing, I take everything into account and release a v2 ASAP.
Guillaume
--
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 Wed, Jun 03, 2015 at 09:55:05AM +, Ed Avis wrote:
> Jeff King peff.net> writes:
>
> If my personal experience is anything to go by, newcomers may fall into the
> habit of running 'git checkout .' to restore missing files. In the old days
> I would often delete a file and then run 'cvs u
On Tue, Jun 02, 2015 at 12:57:08PM -0700, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> > This submodule configuration cache allows us to lazily read .gitmodules
> > configurations by commit into a runtime cache which can then be used to
> > easily lookup values from it. Currently only the valu
On 2015-06-03 11.55, Ed Avis wrote:
> Jeff King peff.net> writes:
>
>> I would say the more "usual" way to use checkout like this
>> is to give specific paths. I.e., run "git status", say "oh, I need to
>> restore the contents of 'foo', but not 'bar'", and run "git checkout
>> foo". That works re
On June 3, 2015 3:06 PM Jeff King wrote:
> On Wed, Jun 03, 2015 at 10:32:40AM -0700, Junio C Hamano wrote:
> > "git checkout $paths" (and you can give "." for $paths to mean
> > "everything") is akin to "cp -R $elsewhere/$path ." to restore the
> > working tree copies from somewhere else.
> >
> > "
Junio C Hamano writes:
> But what if you got this back after the user edits?
>
> drop
> pick 2c9c1c5 gostak: distim doshes
> drop e3b601d pull: use git-rev-parse...
> edit eb2a8d9 pull: handle git-fetch'...
>
> [...]
> Did the user tried to drop something else but the
> object na
On Wednesday, June 3, 2015, Galan Rémi
wrote:
> Check if commits were removed (i.e. a line was deleted) and print
> warnings or abort git rebase depending on the value of the
> configuration variable rebase.missingCommits.
A few comments below in addition to those already made by Matthieu...
> d
On Wed, Jun 03, 2015 at 10:32:40AM -0700, Junio C Hamano wrote:
> "git checkout $paths" (and you can give "." for $paths to mean
> "everything") is akin to "cp -R $elsewhere/$path ." to restore the
> working tree copies from somewhere else.
>
> "Ouch, 'git checkout .' overwrote what was in my wo
> "Konstantin" == Konstantin Khomoutov writes:
Konstantin> On Wed, 3 Jun 2015 17:22:57 +0200
Konstantin> Fabrizio Mancin wrote:
>> I've a little request for you.
>> What about saving date-time on git stash save command and show it on
>> git stash show stash@{xxx}?
>> I think it is a useful
Jeff King writes:
> On Wed, Jun 03, 2015 at 03:51:59PM +0200, Michael Haggerty wrote:
>
>> NULL_SHA1 is used to indicate of "invalid SHA-1" throughout our code
>
> s/of/an/ ?
Also possibly s/invalid SHA-1/invalid ref/?
>> (and the code of other git implementations), so it is vastly more
>> like
Matthieu Moy writes:
> Guillaume Pagès writes:
>
>> Signed-off-by: Guillaume Pagès
>> ---
>> t/t7512-status-help.sh | 227
>> ++---
>
> Your history is not bisectable if you sparate tests and code changes in
> two patches.
Yes.
And by squashing the
Yauheni Zablotski writes:
> Hello,
>
> I think I found a bug(or strange behavior) in the git.
> If commit message contains literal "$message" than that literal
> disappears from commit message.
>
> For example:
> -
> user@comp ~/cc $ git commit -am "1$message1"
Not a Git issue, but a
On June 3, 2015 2:11 PM Junio C Hamano wrote:
> "Randall S. Becker" writes:
> > On June 3, 2015 1:35 PM Junio C Hamano wrote:
> >> Is that really true? It all depends on why you came to a situation
> >> to have "missing files" in the first place, I would think, but "git
> >> checkout $path" is "I
Yauheni Zablotski writes:
> Hello,
>
> I think I found a bug(or strange behavior) in the git.
> If commit message contains literal "$message" than that literal
> disappears from commit message.
>
> For example:
> -
> user@comp ~/cc $ git commit -am "1$message1"
> [master (root-commit)
Maybe the expectation comes from the existing warnings when checking
out branches?
$ mkdir tmp && cd tmp
$ git init
$ echo Hello >foo
$ git add foo
$ git commit -am "Hello"
$ git branch next
$ echo "world" >bar
$ git add bar
$ git commit -a -m "World"
$ git
"Randall S. Becker" writes:
> On June 3, 2015 1:35 PM Junio C Hamano wrote:
>> Is that really true? It all depends on why you came to a
>> situation to have "missing files" in the first place, I would
>> think, but "git checkout $path" is "I messed up the version in
>> the working tree at $path,
Remi Galan Alfonso writes:
> Matthieu Moy writes:
>> You're using $1 and $2 only to redirect input and output. I would find
>> it more elegant to write todo_list_to_sha_list as a filter, and do the
>> redirection in the call site (to keep the option of using
>> todo_list_to_sha_list in a pipe).
Galan Rémi writes:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index dc3133f..869cc60 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -152,6 +152,7 @@ Commands:
> s, squash = use commit, but meld into previous commit
> f, fixup =
Matthieu Moy writes:
> You're using $1 and $2 only to redirect input and output. I would find
> it more elegant to write todo_list_to_sha_list as a filter, and do the
> redirection in the call site (to keep the option of using
> todo_list_to_sha_list in a pipe).
If I understood correctly, then th
Remi Galan Alfonso
writes:
> Junio C Hamano writes:
>> As long as what is given to 'drop'
>> is checked when it matters (e.g. when the code in patch 2/2 tries
>> see if some commits in the original list are no longer there in
>> order to warn sees "drop foo bar" where "foo" is obviously not
On June 3, 2015 1:35 PM Junio C Hamano wrote:
> Ed Avis writes:
> > If my personal experience is anything to go by, newcomers may fall
> > into the habit of running 'git checkout .' to restore missing files.
> Is that really true? It all depends on why you came to a situation to
have
> "missing f
On Tue, Jun 2, 2015 at 11:49 PM, Paul Tan wrote:
> At the beginning of the rewrite of git-pull.sh to C, we introduced a
> redirection to git-pull.sh if the environment variable
> _GIT_USE_BUILTIN_PULL was not defined in order to not break test scripts
> that relied on a functional git-pull.
>
> No
Guillaume Pagès writes:
> Signed-off-by: Guillaume Pagès
> ---
> t/t7512-status-help.sh | 227
> ++---
Your history is not bisectable if you sparate tests and code changes in
two patches.
Plus, as a reviewer, I like seeing changes to the tests next
Galan Rémi writes:
> Check if commits were removed (i.e. a line was deleted) and print
> warnings or abort git rebase depending on the value of the
> configuration variable rebase.missingCommits.
Spelled missingCommitsCheck everywhere else.
> +rebase.missingCommitsCheck::
> + If set to "war
On Tue, Jun 2, 2015 at 11:49 PM, Paul Tan wrote:
> Tweak the error messages printed by die_no_merge_candidates() to take
> into account that we may be "rebasing against" rather than "merging
> with".
>
> Signed-off-by: Paul Tan
> ---
>
> Notes:
> v2
>
> * Decided to use fprintf_ln() for t
Ed Avis writes:
> If my personal experience is anything to go by, newcomers may fall into the
> habit of running 'git checkout .' to restore missing files.
Is that really true? It all depends on why you came to a situation
to have "missing files" in the first place, I would think, but "git
chec
Matthieu Moy writes
> Most git-*.txt do not have this CONFIGURATION section.
>
> In an ideal world, we would have such section automatically generated
> (i.e. the description for each variable would exist in one place, and we
> would make sure that both "man git-config" and "man git-" show
> it
Jeff King writes:
> If we want to introduce more safety here, I'd be inclined to perform the
> operation by default, but give a better escape hatch. For example, by
> creating a loose object for any file we're about to overwrite, and
> possibly writing an entry into a log.
Can we borrow the idea
Jeff King writes:
> My concern there would be risk of regression. I.e., that we would take
> some case which used to error out and turn it into a silent noop. So I'd
> prefer to keep the behavior the same, and just modify the error code
> path. The end result is pretty similar to the user, becaus
On Tue, Jun 2, 2015 at 11:48 PM, Paul Tan wrote:
> Since eb2a8d9 (pull: handle git-fetch's options as well, 2015-06-02),
> git-pull knows about and handles git-fetch's options, passing them to
> git-fetch. Re-implement this behavior.
>
> Since 29609e6 (pull: do nothing on --dry-run, 2010-05-25) gi
Guillaume Pagès writes:
> + if (!fclose(fp))
> + strbuf_detach(&buf, NULL);
> + else
> + strbuf_release(&buf);
Why these two cases? Aren't you leaking the buffer when calling
strbuf_detach and ignoring its return value?
(In general, there's not much to do when fc
Hi,
Your code is not C90:
wt-status.c: In function ‘get_two_last_lines’:
wt-status.c:1030:2: error: ISO C90 forbids mixed declarations and code
[-Werror=declaration-after-statement]
struct strbuf buf = STRBUF_INIT;
^
wt-status.c: In function ‘get_two_first_lines’:
wt-status.c:1050:2: error:
On Tue, Jun 2, 2015 at 11:48 PM, Paul Tan wrote:
> Certain git commands, such as git-pull, are simply wrappers around other
> git commands like git-fetch, git-merge and git-rebase. As such, these
> wrapper commands will typically need to "pass through" command-line
> options of the commands they w
Hello,
I think I found a bug(or strange behavior) in the git.
If commit message contains literal "$message" than that literal
disappears from commit message.
For example:
-
user@comp ~/cc $ git commit -am "1$message1"
[master (root-commit) d36a841] 1
1 file changed, 0 insertions(+),
Matthieu Moy writes
> Remi Lespinet writes:
>
> > +am.threeWay::
> > +By default, git-am will fail if the patch does not apply cleanly.
>
> http://article.gmane.org/gmane.comp.version-control.git/270538
Ok sorry.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe git
Matthieu Moy writes:
>> OPTIONS
>> ---
>> (|)...::
>> @@ -43,11 +53,11 @@ OPTIONS
>> --keep-non-patch::
>> Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
>>
>> ---[no-]keep-cr::
>> +--keep-cr::
>> +--no-keep-cr::
>> With `--keep-cr`, call 'git mailsplit' (see
On 06/03/2015 09:38 PM, Matthieu Moy wrote:
Karthik Nayak writes:
Matthieu Moy suggested that I work on the unification of these
commands let both the implementations stay where the user can select
the implementation to be used
Just to be clear: my advice is the above with "user" = "caller o
Remi Lespinet writes:
> +am.threeWay::
> + By default, git-am will fail if the patch does not apply cleanly.
http://article.gmane.org/gmane.comp.version-control.git/270538
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
Remi Lespinet writes:
> Prepare a configuration section for the git am documentation.
Most git-*.txt do not have this CONFIGURATION section.
In an ideal world, we would have such section automatically generated
(i.e. the description for each variable would exist in one place, and we
would make
Karthik Nayak writes:
> Matthieu Moy suggested that I work on the unification of these
> commands let both the implementations stay where the user can select
> the implementation to be used
Just to be clear: my advice is the above with "user" = "caller of the
API", not "human being using Git". I
On Wed, 3 Jun 2015 17:22:57 +0200
Fabrizio Mancin wrote:
> I've a little request for you.
> What about saving date-time on git stash save command and show it on
> git stash show stash@{xxx}?
> I think it is a useful poperty to save.
>
> What do you think about it?
This information is already th
On di, 2015-06-02 at 23:48 -0700, Junio C Hamano wrote:
>
> I am kind of surprised after reading these two threads that my
> take on this issue has changed over time, as my knee-jerk
> reaction before reading them was the opposite, something
> along the lines of "This is only immediately after 'gi
Hi Guys,
I've a little request for you.
What about saving date-time on git stash save command and show it on
git stash show stash@{xxx}?
I think it is a useful poperty to save.
What do you think about it?
Thank you
Fabrizio
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
On Wed, Jun 03, 2015 at 03:51:59PM +0200, Michael Haggerty wrote:
> NULL_SHA1 is used to indicate of "invalid SHA-1" throughout our code
s/of/an/ ?
> (and the code of other git implementations), so it is vastly more
> likely that a reference was set to this value due to a software bug
> than tha
NULL_SHA1 is used to indicate of "invalid SHA-1" throughout our code
(and the code of other git implementations), so it is vastly more
likely that a reference was set to this value due to a software bug
than that NULL_SHA1 is the legitimate SHA-1 of an actual object.
Therefore, if a loose reference
If there is a loose reference file with invalid contents, "git
for-each-ref" incorrectly reports the problem as being a missing
object with name NULL_SHA1:
$ echo '12345678' >.git/refs/heads/nonsense
$ git for-each-ref
fatal: missing object for
Make it clearer that there are two possible ways to read the
reference, but that we handle read errors uniformly regardless of
which way it was read.
This refactoring also makes the following change easier to implement.
Signed-off-by: Michael Haggerty
---
refs.c | 19 ---
1 file
This reroll addresses all of the comments about v1 [1] and v2 [2].
Thanks to Stefan, Junio, and Peff for their comments about v2.
Changes since v2:
* Simplify logic flow in read_loose_refs().
* Remove unnecessary call to hashclr() in read_loose_refs().
* Improve a comment and commit message.
Thi
Add tests that for-each-ref correctly reports broken loose reference
files and references that point at missing objects. In fact, two of
these tests fail, because (1) NULL_SHA1 is not recognized as an
invalid reference value, and (2) for-each-ref doesn't respect
REF_ISBROKEN. Fixes to come.
Note t
Hi again,
just wanted to tell that I have created a solution by doing a few lines
of scripting:
git-cstash
```
#/bin/sh
git commit -m 'temporary, will be stashed soon'
git stash --include-untracked
git reset HEAD^1
git stash
git stash pop stash@{1}
```
Le 2015-04-22 11:25, Johannes Schindeli
Galan Rémi writes:
> +comm -2 -3 "$todo".oldsha1 "$todo".newsha1 >"$todo".miss
> +
> +# Make the list user-friendly
> +opt="--no-walk=sorted --format=oneline --abbrev-commit
> --stdin"
> +git rev-list $opt <"$todo".miss >"$todo".miss
When I checkout a particular commit in my repo and immediately do a
git status, there is a file that show up as changed. If I look at the
SHAs for my working copy and the copy in the index/repo, they are
indeed different. The working copy has carriage returns, and while I
*suspect* the copy in the
Check if commits were removed (i.e. a line was deleted) and print
warnings or abort git rebase depending on the value of the
configuration variable rebase.missingCommits.
This patch gives the user the possibility to avoid silent loss of
information (losing a commit through deleting the line in thi
Instead of removing a line to remove the commit, you can use the
command "drop" (just like "pick" or "edit"). It has the same effect as
deleting the line (removing the commit) except that you keep a visual
trace of your actions, allowing a better control and reducing the
possibility of removing a c
On Wed, Jun 03, 2015 at 02:49:01PM +0800, Paul Tan wrote:
> Re-implement the behavior introduced by f9189cf (pull --rebase: exit
> early when the working directory is dirty, 2008-05-21).
When the option rebase.autoStash is set, it should not be necessary to
die in this case. See also this[1] patch
Hi,
Git Rev News edition 4 is now available:
https://git.github.io/rev_news/2015/06/03/edition-4/
Thanks a lot to all the helpers!
Enjoy,
Christian, Thomas and Nicola.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More ma
Jeff King peff.net> writes:
>I would say the more "usual" way to use checkout like this
>is to give specific paths. I.e., run "git status", say "oh, I need to
>restore the contents of 'foo', but not 'bar'", and run "git checkout
>foo". That works regardless of the type of change to "foo" and "bar
On Wed, Jun 03, 2015 at 09:21:59AM +, Ed Avis wrote:
> I had expected that 'git checkout .' would fix up my working tree to make it
> match the repository (in this case, the current revision of the master
> branch).
It did. :)
> The user interface might be something like:
>
> % git checkout
I had expected that 'git checkout .' would fix up my working tree to make it
match the repository (in this case, the current revision of the master
branch). When I originally ran it I had deleted a couple of files from the
working tree and wanted to restore them. However, I expected that if doing
Junio C Hamano writes:
> As long as what is given to 'drop'
> is checked when it matters (e.g. when the code in patch 2/2 tries
> see if some commits in the original list are no longer there in
> order to warn sees "drop foo bar" where "foo" is obviously not an
> object name in the original l
On Tue, Jun 02, 2015 at 11:10:22PM +0200, Michael Haggerty wrote:
> >> +
> >> + if (!(flag & REF_ISBROKEN) && is_null_sha1(sha1)) {
> >
> > Why do we do the extra check for !(flag & REF_ISBROKEN) here?
>
> That was an attempt to avoid calling is_null_sha1() unnecessarily. I
On Wed, Jun 03, 2015 at 08:50:44AM +, Ed Avis wrote:
> Currently a plain 'git checkout .' will revert any local changes, e.g.
>
> % mkdir test
> % cd test
> % git init
> Initialized empty Git repository in /home/eda/test/.git/
> % echo hello >foo
> % git add foo
>
Currently a plain 'git checkout .' will revert any local changes, e.g.
% mkdir test
% cd test
% git init
Initialized empty Git repository in /home/eda/test/.git/
% echo hello >foo
% git add foo
% git commit -m.
[master (root-commit) 34f6694] .
1 file changed, 1
git status gives more information during rebase -i, about the list of
command that are done during the rebase. It displays the two last
commands executed and the two next lines to be executed. It also gives
hints to find the whole files in .git directory.
Signed-off-by: Guillaume Pagès
---
At th
Signed-off-by: Guillaume Pagès
---
t/t7512-status-help.sh | 227 ++---
1 file changed, 213 insertions(+), 14 deletions(-)
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index 68ad2d7..242124f 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7
> On 06/03/2015 07:50 AM Torsten Bögershausen wrote
>
> > +CONFIGURATION
> > +-
> > +
> > +am.keepcr::
> > +If true, git-am will call git-mailsplit for patches in mbox format
> > +with parameter '--keep-cr'. In this case git-mailsplit will
> > +not remove `\r` f
> Matthieu Moy writes:
> > Ideally, you would check the list of commits displayed too. If the
> > commits sha1 are stable, this should be easy to do. If it's too hard to
> > test, I'd say its not worth the trouble, but others may disagree.
>
> Originally I chose not to check if the SHA-1 were
On Thu, May 28, 2015 at 5:53 AM, Jeff King wrote:
> On Wed, May 27, 2015 at 09:03:47PM +0200, Torsten Bögershausen wrote:
>
>> The original open can take 2 or 3 parameters, how about this:
>> int xopen(const char *path, int oflag, ... )
>> {
>> va_list params;
>> int mode;
>>
On Tue, Jun 02, 2015 at 11:48:30PM -0700, Junio C Hamano wrote:
> I am kind of surprised after reading these two threads that my
> take on this issue has changed over time, as my knee-jerk
> reaction before reading them was the opposite, something
> along the lines of "This is only immediately aft
On Thu, May 28, 2015 at 4:44 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> @@ -17,6 +34,10 @@ struct am_state {
>> struct strbuf dir;/* state directory path */
>> int cur; /* current patch number */
>> int last; /* last pa
On Thu, May 28, 2015 at 6:13 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> +static const char *msgnum(const struct am_state *state)
>> +{
>> + static struct strbuf fmt = STRBUF_INIT;
>> + static struct strbuf sb = STRBUF_INIT;
>> +
>> + strbuf_reset(&fmt);
>> + strbuf_addf(&fm
Matthieu Moy writes:
> Ideally, you would check the list of commits displayed too. If the
> commits sha1 are stable, this should be easy to do. If it's too hard to
> test, I'd say its not worth the trouble, but others may disagree.
Originally I chose not to check if the SHA-1 were corrects since
90 matches
Mail list logo
