On Mon, 18 Nov 2013 18:42:26 +0100
Philippe Vaucher philippe.vauc...@gmail.com 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
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. I
Matthieu Moy matthieu@grenoble-inp.fr 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
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
Ramkumar Ramachandra artag...@gmail.com 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
Thomas Koch tho...@koch.ro 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
Thomas Koch tho...@koch.ro 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
Andrés G. Aragoneses kno...@gmail.com 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 depth0 should be simply invalid,
and under the
Junio C Hamano gits...@pobox.com 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
Ramkumar Ramachandra artag...@gmail.com 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 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
order to
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
message
Jens Lehmann jens.lehm...@web.de 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
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 this
Jens Lehmann jens.lehm...@web.de 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
Junio C Hamano gits...@pobox.com writes:
Jens Lehmann jens.lehm...@web.de 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
Jens Lehmann jens.lehm...@web.de writes:
Am 18.11.2013 17:01, schrieb Junio C Hamano:
Jeff King p...@peff.net 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
Am 19.11.2013 21:34, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
Am 18.11.2013 17:01, schrieb Junio C Hamano:
Jeff King p...@peff.net 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
From: Jonathan Nieder jrnie...@gmail.com
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
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
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
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
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 replace it
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 chrisc...@tuxfamily.org
---
git-compat-util.h | 1 -
strbuf.c | 9 -
2 files changed, 10 deletions(-)
diff --git
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
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
---
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
On Tue, Nov 19, 2013 at 10:04 PM, Christian Couder
chrisc...@tuxfamily.org 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
Christian Couder christian.cou...@gmail.com 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
Jim Garrison jim.garri...@nwea.org 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
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 learn
Bug
===
The command
git rebase --whitespace=fix --keep-empty commit
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
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.
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
On Tue, Nov 19, 2013 at 7:31 PM, Jonathan Nieder jrnie...@gmail.com 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
Jason St. John wrote:
On Tue, Nov 19, 2013 at 7:31 PM, Jonathan Nieder jrnie...@gmail.com 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
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
Replace double quotes around literal examples with backticks
Signed-off-by: Jason St. John jstj...@purdue.edu
---
Documentation/gitcli.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 3146413..41bed29
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
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 getting
On Tue, Nov 19, 2013 at 5:50 PM, Tim Chase g...@tim.thechases.com 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
On Tue, Nov 19, 2013 at 8:50 PM, Tim Chase g...@tim.thechases.com 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
-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
Jason St. John jstj...@purdue.edu 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
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. I
43 matches
Mail list logo
