Am 11/20/2013 4:49, schrieb Matthew Cengia:
> The other day I was merging a feature branch (shown below as
> origin/22869-new-kernel) into my staging release (shown below as 'wtf'),
> and it *reverted* a bucket-load of changes I'd made on other branches
> which had been merged into staging before.
"Jason St. John" writes:
> Documentation/git-rebase.txt: add a blank line after the two AsciiDoc
> listing blocks
That looks funnily formatted, out of place and redundant.
> Without these blank lines, AsciiDoc thinks the opening "-" is a
> section heading and typesets the word "to" as s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
The other day I was merging a feature branch (shown below as
origin/22869-new-kernel) into my staging release (shown below as 'wtf'),
and it *reverted* a bucket-load of changes I'd made on other branches
which had been merged into staging before. I c
On Tue, Nov 19, 2013 at 8:50 PM, Tim Chase wrote:
> Having lost "add -p" work enough times when stashing, I finally
> dug into the docs to see how to prevent it, discovering that
> "--keep-index" does exactly what I want. However, now I have trouble
> remembering to add the "--keep-index" until a
On Tue, Nov 19, 2013 at 5:50 PM, Tim Chase wrote:
> Having lost "add -p" work enough times when stashing, I finally
> dug into the docs to see how to prevent it, discovering that
> "--keep-index" does exactly what I want.
Note that 'git stash (pop | apply) --index' will reinstate the index
as it
Having lost "add -p" work enough times when stashing, I finally
dug into the docs to see how to prevent it, discovering that
"--keep-index" does exactly what I want. However, now I have trouble
remembering to add the "--keep-index" until after I've shot myself in
the foot. How do I go about getti
Signed-off-by: Nguyễn Thái Ngọc Duy
---
This is yet another stab at the negative pathspec thing. It's not
ready yet (there are a few XXXs) but I could use some feedback
regarding the interface, or the behavior. It looks better this time
now that pathspec magic is supported (or maybe I'm just
Replace double quotes around literal examples with backticks
Signed-off-by: Jason St. John
---
Documentation/gitcli.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 3146413..41bed29 100644
--- a/Documenta
builtin_diff_b_f() needs a path, not pathspec. Other modes in diff
can deal with pathspec just fine. But because of the current
GUARD_PATHSPEC() location, other modes also reject :(glob) and
:(icase).
Move GUARD_PATHSPEC(), and the "path" assignment statement, which is
the reason of this GUARD_PAT
Jason St. John wrote:
> On Tue, Nov 19, 2013 at 7:31 PM, Jonathan Nieder wrote:
>> Jason St. John wrote:
>>> Documentation/git-rebase.txt: add a blank line after the two AsciiDoc
>>> listing blocks
>>
>> I'd leave out the above two description lines, since they're redundant
>> next to the pat
On Tue, Nov 19, 2013 at 7:31 PM, Jonathan Nieder wrote:
> Hi,
>
> Jason St. John wrote:
>
>> Documentation/git-rebase.txt: add a blank line after the two AsciiDoc
>> listing blocks
>
> I'd leave out the above two description lines, since they're redundant
> next to the patch text.
>
I include
Hi,
Jason St. John wrote:
> Documentation/git-rebase.txt: add a blank line after the two AsciiDoc
> listing blocks
I'd leave out the above two description lines, since they're redundant
next to the patch text.
> Without these blank lines, AsciiDoc thinks the opening "-" is a
> section h
Documentation/git-rebase.txt: add a blank line after the two AsciiDoc
listing blocks
Without these blank lines, AsciiDoc thinks the opening "-" is a
section heading and typesets the word "to" as such, which causes
cascading formatting/typesetting issues until the end of the document.
Sign
Bug
===
The command
git rebase --whitespace=fix --keep-empty
does not fix whitespace in the rebased commits.
Example
===
Set up a repo with a whitespace error commit and an empty commit:
git init rebase-bug.git
cd rebase-bug.git
touch foo
git add foo
touch foo
git add foo
Antoine Pelisse writes:
> On Tue, Nov 19, 2013 at 10:04 PM, Christian Couder
> wrote:
>> To avoid spamming the list again, I am going to send the following
>> patches from the 86 patch long series to replace prefixcmp() with
>> starts_with():
>>
>> [PATCH v2 00/86] replace prefixcmp() with start
Hi,
Jim Garrison wrote:
> The master reference TOC page at http://git-scm.com/docs links to
> all the associated command reference pages, except it seems to be
> missing a link for gitrevisions(7)
> (http://git-scm.com/docs/gitrevisions.html).
>
> I've never submitted a patch and thought I would
Jim Garrison writes:
> The master reference TOC page at http://git-scm.com/docs links to all
> the associated command reference pages, except it seems to be missing
> a link for gitrevisions(7)
> (http://git-scm.com/docs/gitrevisions.html).
>
> I've never submitted a patch and thought I would lea
Christian Couder writes:
> There is also a new version of my 86 patch long series to replace
> prefixcmp() with starts_with() that I am ready to send, but I hesitate
> to spam the whole list :-)
> I can put it somewhere like GitHub where people can see everything and
> perhaps send only a few pat
On Tue, Nov 19, 2013 at 10:04 PM, Christian Couder
wrote:
> To avoid spamming the list again, I am going to send the following
> patches from the 86 patch long series to replace prefixcmp() with
> starts_with():
>
> [PATCH v2 00/86] replace prefixcmp() with starts_with()
> [PATCH v2 01/86] strbuf:
The master reference TOC page at http://git-scm.com/docs links to all the
associated command reference pages, except it seems to be missing a link for
gitrevisions(7) (http://git-scm.com/docs/gitrevisions.html).
I've never submitted a patch and thought I would learn how... except the
website so
Signed-off-by: Christian Couder
---
environment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/environment.c b/environment.c
index 378254c..1270278 100644
--- a/environment.c
+++ b/environment.c
@@ -176,7 +176,7 @@ const char *get_git_namespace(void)
const char *strip_na
Signed-off-by: Christian Couder
---
transport-helper.c | 16
transport.c| 28 ++--
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index b32e2d6..96de26d 100644
--- a/transport-helper.c
+++ b
prefixcmp() cannot be really used as a comparison function as
it is not antisymmetric:
prefixcmp("foo", "foobar") < 0
prefixcmp("foobar", "foo") == 0
So it is not suitable as a function for passing to qsort.
And in fact it is used nowhere as a comparison function.
So we should re
prefixcmp() is now useless as the previous commit replaced it
everywhere with starts_with(). So let's now remove it.
Signed-off-by: Christian Couder
---
git-compat-util.h | 1 -
strbuf.c | 9 -
2 files changed, 10 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
Here is a resend of a big patch series to replace prefixcmp()
with a new starts_with() function.
The changes since the previous version are the following
- the function to replace prefixcmp() is now
starts_with()
- the mispelling of prefixcmp() in the titles
of
Signed-off-by: Christian Couder
---
diff.c | 56
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/diff.c b/diff.c
index a04a34d..4b42997 100644
--- a/diff.c
+++ b/diff.c
@@ -235,7 +235,7 @@ int git_diff_basic_config(const cha
From: Jonathan Nieder
> Christian Couder wrote:
>
>> And in vcs-svn/fast_export.c there was already an ends_with()
>> function that did the same thing. Let's used the renamed one
>> while at it.
>
> Yes, despite the change in signature this shouldn't slow anything
> down. Thanks.
>
> For what
Am 19.11.2013 21:34, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> Am 18.11.2013 17:01, schrieb Junio C Hamano:
>>> Jeff King writes:
>>>
I found this hard to parse, I think because of the "keeping" (why would
I not keep it?), and because you are talking about lines above and
>>>
Jens Lehmann writes:
> Am 18.11.2013 17:01, schrieb Junio C Hamano:
>> Jeff King writes:
>>
>>> I found this hard to parse, I think because of the "keeping" (why would
>>> I not keep it?), and because you are talking about lines above and
>>> below. It is not as accurate to say:
>>>
>>> # ---
Junio C Hamano writes:
> Jens Lehmann writes:
>
>> diff --git a/wt-status.h b/wt-status.h
>> index 6c29e6f..cd2709f 100644
>> --- a/wt-status.h
>> +++ b/wt-status.h
>> @@ -91,6 +91,8 @@ struct wt_status_state {
>> unsigned char cherry_pick_head_sha1[20];
>> };
>>
>> +const char wt_status_d
Jens Lehmann writes:
> diff --git a/wt-status.h b/wt-status.h
> index 6c29e6f..cd2709f 100644
> --- a/wt-status.h
> +++ b/wt-status.h
> @@ -91,6 +91,8 @@ struct wt_status_state {
> unsigned char cherry_pick_head_sha1[20];
> };
>
> +const char wt_status_diff_divider[];
This gives me:
./wt
Christian Couder wrote:
> Now ends_with() returns 1 when the suffix is present and 0 otherwise.
Sounds good.
[...]
> And in vcs-svn/fast_export.c there was already an ends_with()
> function that did the same thing. Let's used the renamed one
> while at it.
Yes, despite the change in signature t
Jens Lehmann writes:
> When using the '-v' option of "git commit" the diff added to the commit
> message temporarily for editing is stripped off after the user exited the
> editor by searching for "\ndiff --git " and truncating the commmit message
> there if it is found. But this approach has two
When using the '-v' option of "git commit" the diff added to the commit
message temporarily for editing is stripped off after the user exited the
editor by searching for "\ndiff --git " and truncating the commmit message
there if it is found. But this approach has two problems: when the commit
mess
Junio C Hamano wrote:
> My knee-jerk "adding it to struct refinfo" is not correct, either,
> because what we want to know, i.e. "do we need an extra reset?" is
> not a property for each ref. It is similar to "what is the set of
> atoms the format string is using?" and "do we need to peel tags in
>
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
>>> index 2ff4e54..04e35ba 100644
>>> --- a/builtin/for-each-ref.c
>>> +++ b/builtin/for-each-ref.c
>>> @@ -23,6 +23,7 @@ typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME }
>>>
Junio C Hamano writes:
> Perhaps I am being naïve, but I would expect that a GUI is a much
> better vehicle to help users build the right mental model.
One thing the command-line does well is to give names to concepts
(basically, command names, option names, ...). It's easy to write in a
tutoria
"Andrés G. Aragoneses" writes:
> Instead of simply ignoring the value passed to --depth
> option when it is zero or negative, now it is caught
> and reported.
>
> This will let people know that they were using the
> option incorrectly (as depth<0 should be simply invalid,
> and under the hood dep
Thomas Koch writes:
> But also from experience I can tell that without exception everybody whom I
> teached Git understood it only after being introduced to the basic concepts
> of
> Git and how to inspect and operate them on the commandline. Others told me
> from similar experiences.
>
> Thos
Thomas Koch writes:
> I'm a software engineer now with an education as a high school teacher. From
> a
> theoretical point of view it's preferable to avoid any abstraction done by a
> GUI and use commandline Git. Only gitk is useful to have a visual _feedback_
> of the actions done on the com
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>
>> Isn't a new single bit in "struct refinfo" all you need to keep
>> track of, to see the last %(color:something) you ever saw is for a
>> color that is not reset?
>
> No; because I can only look at one atom and set v->color, at a time.
Tha
Sir/Madam,fast and reliable financial support I offer loan of €5,000 to
€950,000 to anyone able to repay with interest. For anyone interested email me
URGENTLY Name,Amount,Duration,Phone and Country,age,sex
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
Matthieu Moy writes:
[...]
> I was wondering whether others had similar (or not) experience. In
> particular, as a teacher, I'm wondering whether I should push my
> students towards the GUI in the IDE, or advise them to keep using the
> command-line (we teach them git with the command-line firs
On Monday, November 18, 2013 06:11:54 PM Matthieu Moy wrote:
> Hi,
>
> I'm normally an Emacs+command-line user, but I also use Eclipse or
> Netbeans on some projects. I tried using EGit and the Netbeans plugin
> for Git, but found the GUI both more comlex and less powerful than the
> command-line.
On Mon, 18 Nov 2013 18:42:26 +0100
Philippe Vaucher wrote:
[...]
> When they understand git reasonably (or if they are not lazy people
> and willing to learn), then show them full integrations like
> TortoiseGit (or probably the Netbeans plugin), which are nice when
> everything works but you hav
45 matches
Mail list logo
