Konstantin == Konstantin Khomoutov kostix+...@007spb.ru writes:
Konstantin On Wed, 3 Jun 2015 17:22:57 +0200
Konstantin Fabrizio Mancin fabma...@gmail.com 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
On Wednesday, June 3, 2015, Galan Rémi
remi.galan-alfo...@ensimag.grenoble-inp.fr 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
Junio C Hamano gits...@pobox.com 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
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
From: Ed Avis e...@waniasset.com
Sent: Wednesday, June 03, 2015 10:55 AM
Jeff King peff at 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
On Wed, Jun 03, 2015 at 11:51:43AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
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 working tree is
On Tue, Jun 02, 2015 at 12:57:08PM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net 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
On Wed, Jun 03, 2015 at 09:55:05AM +, Ed Avis wrote:
Jeff King peff at 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
add support for negative pattern matching in @^{/pattern} 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,
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
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
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.
Ouch, 'git checkout
Eric Sunshine sunsh...@sunshineco.com 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.
On 2015-06-03 11.55, Ed Avis wrote:
Jeff King peff at 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
On Wed, Jun 03, 2015 at 06:08:50PM +0200, Matthieu Moy wrote:
Karthik Nayak karthik@gmail.com 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:
On Wed, Jun 3, 2015 at 10:52 PM, Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com 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
---
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
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
Jeff King p...@peff.net writes:
On Wed, Jun 03, 2015 at 11:51:43AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Will Palmer wmpal...@gmail.com 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
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
Jeff King p...@peff.net 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
Jeff King peff at 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.
That
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 commit
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
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
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28), if the
--rebase option is set, git-rebase is run instead of git-merge.
Re-implement this by introducing run_rebase(), which is called instead
of run_merge() if opt_rebase is a true value.
Since c85c792 (pull --rebase: be cleverer with
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 pyoka...@gmail.com
---
Notes:
v2
* Decided to use fprintf_ln() for the sake of code consistency, and for
the
Re-implement the behavior introduced by f9189cf (pull --rebase: exit
early when the working directory is dirty, 2008-05-21).
Signed-off-by: Paul Tan pyoka...@gmail.com
---
builtin/pull.c | 77 +-
1 file changed, 76 insertions(+), 1
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) git-pull
supported the --dry-run option, exiting after
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.
Now that all of git-pull's functionality has been
When we have a null-terminated array, it would be useful to convert it
or append it to an argv_array for further manipulation.
Implement argv_array_pushv() which will push a null-terminated array of
strings on to an argv_array.
Signed-off-by: Paul Tan pyoka...@gmail.com
---
7f87aff (Teach/Fix pull/fetch -q/-v options, 2008-11-15) taught git-pull
to accept the verbosity -v and -q options and pass them to git-fetch and
git-merge.
Re-implement support for the verbosity flags by adding it to the options
list and introducing argv_push_verbosity() to push the flags into
f947413 (Use GIT_REFLOG_ACTION environment variable instead.,
2006-12-28) established git-pull's method for setting the reflog
message, which is to set the environment variable GIT_REFLOG_ACTION to
the evaluation of pull${1+ $*} if it has not already been set.
Re-implement this behavior.
Since b814da8 (pull: add pull.ff configuration, 2014-01-15), git-pull.sh
would lookup the configuration value of pull.ff, and set the flag
--ff if its value is true, --no-ff if its value is false and
--ff-only if its value is only.
Re-implement this behavior.
Signed-off-by: Paul Tan
Implement the fetch + merge functionality of git-pull, by first running
git-fetch with the repo and refspecs provided on the command line, then
running git-merge on FETCH_HEAD to merge the fetched refs into the
current branch.
Signed-off-by: Paul Tan pyoka...@gmail.com
---
builtin/pull.c | 61
For the purpose of rewriting git-pull.sh into a C builtin, implement a
skeletal builtin/pull.c that redirects to $GIT_EXEC_PATH/git-pull.sh if
the environment variable _GIT_USE_BUILTIN_PULL is not defined. This
allows us to fall back on the functional git-pull.sh when running the
test suite for
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28),
fetch+rebase could be set by default by defining the config variable
branch.name.rebase. This setting can be overriden on the command line
by --rebase and --no-rebase.
Since 6b37dff (pull: introduce a pull.rebase option to enable
b4dc085 (pull: merge into unborn by fast-forwarding from empty
tree, 2013-06-20) established git-pull's current behavior of pulling
into an unborn branch by fast-forwarding the work tree from an empty
tree to the merge head, then setting HEAD to the merge head.
Re-implement this behavior by
Specify git-merge's options in the option list, and pass any specified
options to git-merge.
These options are:
* -n, --stat, --summary: since d8abe14 (merge, pull: introduce
'--(no-)stat' option, 2008-04-06)
* --log: since efb779f (merge, pull: add '--(no-)log' command line
option,
Commit a8c9bef (pull: improve advice for unconfigured error case,
2009-10-05) fully established the current advices given by git-pull for
the different cases where git-fetch will not have anything marked for
merge:
1. We fetched from a specific remote, and a refspec was given, but it
ended up
On Tue, Jun 2, 2015 at 11:28 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Jun 3, 2015 at 12:51 AM, Jeff King p...@peff.net wrote:
---
I'm also happy to split it into two patches, and make Eric the author on
the MASK part.
I don't mind being an author of a patch, so splitting
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull,
upon detecting that git-fetch updated the current head, will
fast-forward the working tree to the updated head commit.
Re-implement this behavior.
Signed-off-by: Paul Tan pyoka...@gmail.com
---
builtin/pull.c | 30
Since d38a30d (Be more user-friendly when refusing to do something
because of conflict., 2010-01-12), git-pull will error out with
user-friendly advices if the user is in the middle of a merge or has
unmerged files.
Re-implement this behavior. While the has unmerged files case can be
handled by
Signed-off-by: Guillaume Pagès guillaume.pa...@ensimag.grenoble-inp.fr
---
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
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
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
think I can
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
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
On Thu, May 28, 2015 at 4:44 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
@@ -17,6 +34,10 @@ struct am_state {
struct strbuf dir;/* state directory path */
int cur; /* current patch number */
int last;
On Thu, May 28, 2015 at 6:13 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com 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);
+
Matthieu Moy matthieu@grenoble-inp.fr 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
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
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
% git
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 .
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
Checking that the warning was correctly displayed like in the test for
warn if I understood correctly. About that, is checking that the
first line is Warning: some commits may have been dropped
accidentally. (like in the
Matthieu Moy matthieu@grenoble-inp.fr 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
On Wed, Jun 03, 2015 at 11:24:19AM +0530, Tummala Dhanvi wrote:
When we do create a new empty git repo using git init or create a
orphan branch and do a git log then I am getting an error saying that
fatal: bad default revision 'HEAD'
Well the error should have been something like no
On Wed, Jun 3, 2015 at 2:39 AM, Jeff King p...@peff.net wrote:
From: Eric Sunshine sunsh...@sunshineco.com
On PowerPC Mac OS X (10.5.8 Leopard with Xcode 3.1),
system header /usr/include/ppc/param.h[1] pollutes the
preprocessor namespace with a macro generically named MASK.
This conflicts
On Wed, Jun 3, 2015 at 2:39 AM, Jeff King p...@peff.net wrote:
The ewah/ewok.h header pollutes the global namespace with
BITS_IN_WORD, without any specific notion that we are
talking about the bits in an eword_t. We can give this the
more specific name BITS_IN_EWORD.
Signed-off-by: Jeff King
On Wed, Jun 03, 2015 at 02:28:10AM -0400, Eric Sunshine wrote:
On Wed, Jun 3, 2015 at 12:51 AM, Jeff King p...@peff.net wrote:
Subject: [PATCH] ewah: use less generic macro names
The ewah/ewok.h header pollutes the global namespace with
BITS_IN_WORD, without any specific notion that we
From: Eric Sunshine sunsh...@sunshineco.com
On PowerPC Mac OS X (10.5.8 Leopard with Xcode 3.1),
system header /usr/include/ppc/param.h[1] pollutes the
preprocessor namespace with a macro generically named MASK.
This conflicts with the same-named macro in ewah/bitmap.c.
We can avoid this conflict
This is a re-roll of [v1]. Thanks Johannes, Stefan and Junio for the reviews
last round.
Previous versions:
[v1] http://thread.gmane.org/gmane.comp.version-control.git/269258
git-pull is a commonly executed command to check for new changes in the
upstream repository and, if there are, fetch and
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 wrap.
Implement the parse_opt_pass_argv_array()
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 wrap.
Implement the parse_opt_pass_strbuf() parse-options
On Tue, Jun 2, 2015 at 11:20 PM, Jeff King p...@peff.net wrote:
Here are some prior discussions:
http://thread.gmane.org/gmane.comp.version-control.git/75692
http://thread.gmane.org/gmane.comp.version-control.git/200504
I just skimmed through them, but I expect the most desirable
On 06/03/2015 07:50 AM Torsten Bögershausen tbo...@web.de 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`
On Wed, Jun 3, 2015 at 12:51 AM, Jeff King p...@peff.net wrote:
Subject: [PATCH] ewah: use less generic macro names
The ewah/ewok.h header pollutes the global namespace with
BITS_IN_WORD, without any specific notion that we are
talking about the bits in an eword_t. We can give this the
more
On Thu, May 28, 2015 at 5:53 AM, Jeff King p...@peff.net 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;
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
The ewah/ewok.h header pollutes the global namespace with
BITS_IN_WORD, without any specific notion that we are
talking about the bits in an eword_t. We can give this the
more specific name BITS_IN_EWORD.
Signed-off-by: Jeff King p...@peff.net
---
ewah/bitmap.c | 12 ++--
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 after
Junio C Hamano gits...@pobox.com 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
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 that
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
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 mhag...@alum.mit.edu
---
refs.c | 19
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
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
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.
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
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr 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
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 'git
Karthik Nayak karthik@gmail.com 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
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
the
On Wed, 3 Jun 2015 17:22:57 +0200
Fabrizio Mancin fabma...@gmail.com 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
Matthieu Moy matthieu@grenoble-inp.fr writes
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
OPTIONS
---
(mbox|Maildir)...::
@@ -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
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(+), 0
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:
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr 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:
On 06/03/2015 09:38 PM, Matthieu Moy wrote:
Karthik Nayak karthik@gmail.com 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
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr 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
On Tue, Jun 2, 2015 at 11:48 PM, Paul Tan pyoka...@gmail.com 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,
Guillaume Pagès guillaume.pa...@ensimag.grenoble-inp.fr 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
On Tue, Jun 2, 2015 at 11:48 PM, Paul Tan pyoka...@gmail.com 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
1 - 100 of 120 matches
Mail list logo
