David Lang venit, vidit, dixit 04.03.2015 01:53:
On Tue, 3 Mar 2015, Shawn Pearce wrote:
On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller sbel...@google.com wrote:
bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity
Indeed, a DVCS like Git or Hg does not fit everyone. And
On Wed, Mar 04, 2015 at 04:46:47PM +0100, Michael J Gruber wrote:
So, how does this relate to:
http://permalink.gmane.org/gmane.comp.version-control.git/264592
I don't mind you taking this over at all, it's just that we should keep
things together where the discussion begun.
Michael
Kevin Daudt venit, vidit, dixit 04.03.2015 00:12:
Only behaviour with these options are currently explained. Add
explanation what the default behaviour is.
Signed-off-by: Kevin Daudt m...@ikke.info
---
Documentation/git-remote.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
3. Introduce a more trust-worthy mechanism for ordering commits. The
timestamp here is really just a proxy for the oft-discussed
generation number of the commit within the graph. We've avoided
adding
Matthieu Moy matthieu@grenoble-inp.fr writes:
Jeff King p...@peff.net writes:
Maybe something along the lines of If you are really excited about
working on git, we would love to see your application; if you are just
looking for a random project, there may be a lot of competition for a
On Wed, Mar 4, 2015 at 4:05 AM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Mar 4, 2015 at 11:27 AM, Shawn Pearce spea...@spearce.org wrote:
Let me go on a different tangent a bit from the current protocol.
http://www.grpc.io/ was recently released and is built on the HTTP/2
standard. It uses
Chris Pimlott ch...@pimlott.net writes:
It seems that git-describe always thinks that working copy is dirty if
you are not in the WC root and you explicitly specify the .git
directory location using --git-dir:
# set up test repo
folio:~ chris$ mkdir repo cd repo
folio:repo chris$
It seems that git-describe always thinks that working copy is dirty if
you are not in the WC root and you explicitly specify the .git
directory location using --git-dir:
# set up test repo
folio:~ chris$ mkdir repo cd repo
folio:repo chris$ mkdir text echo hi text/hi.txt
folio:repo
Michael J Gruber g...@drmicha.warpmail.net writes:
Ahh, OK. The way the existing tests prepare 'expect' is by hand.
So I think what is wrong with this new test is not that relies on
the current contents of 'expect', but that it modifies it (imagine
being a merge/patch monkey who has to
Section names and variable names are both case-insensitive, but one
is described as not case sensitive. Use case-insensitive for
both.
Instead of saying ... have to be escaped without telling what that
escaping achieves, state it in a more positive way, i.e. ... can be
included by escaping.
In git log --decorate, you would see the commit header like this:
commit ... (HEAD, jc/decorate-leaky-separator-color)
where commit ... ( is painted in color.diff.commit, HEAD in
color.decorate.head, , in color.diff.commit, the branch name in
color.decorate.branch and then closing ) in
A line can be continued via a backquote-LF and can be chomped at a
comment character. But that is not specific to string-typed values.
It is common to all, just like unquoted leading and trailing
whitespaces are stripped and inter-word spacing are retained.
Move the description around and
The syntax section repeats what the preamble explained already.
That a variable can have multiple values is more about what a
variable is than the syntax of the file.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 7 +++
1 file changed, 3 insertions(+), 4
Entries in a ZIP file can be marked as text files. Extractors can use
that flag to apply end-of-line conversions. An example is unzip -a.
git archive currently marks all ZIP file entries as binary files. This
patch adds the new option --text that can be used to mark non-binary
files or all
Instead of describing it for color.branch.slot and have everybody
else refer to it, explain how colors are spelled in Values section
upfront.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 29 +
1 file changed, 13 insertions(+), 16
In git log --decorate, you would see the commit header like this:
commit ... (HEAD, jc/decorate-leaky-separator-color)
where commit ... ( is painted in color.diff.commit, HEAD in
color.decorate.head, , in color.diff.commit, the branch name in
color.decorate.branch and then closing ) in
The various types of values set to the configuration variables
deserve more than a brief footnote mention in the syntax section,
and it will be more so after the later steps of this clean up
effort.
Move the mention of booleans from the syntax section to this new
section, and describe how
The 'true' short-hand doesn't deserve a separate sentence; even our own
git config --bool foo.bar yes
would not produce it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Karthik Nayak karthik@gmail.com writes:
add sha1_object_info_literally() which is to be used when
the literally option is given to get the type of object
and print it, using sha1_object_info_extended().
add unpack_sha1_header_literally() to unpack sha headers
which may be greater than
Michael J Gruber g...@drmicha.warpmail.net writes:
Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:
Michael J Gruber g...@drmicha.warpmail.net writes:
+diff --git INDEX=staged-for-commit/dir1/modified
WORKTREE=not-staged-for-commit/dir1/modified
+index e69de29..d00491f 100644
+---
Michael J Gruber g...@drmicha.warpmail.net writes:
I am not sure how the intention of the commit 1c2eafb8 (Add
url.base.pushInsteadOf: URL rewriting for push only, 2009-09-07),
which introduced the behaviour verified by this test, interacts with
the desire to redefine what URL and pushURL
Anton Trunov anton.a.tru...@gmail.com writes:
For the code version before applying this patch the following scenario
will take place if git merge -Xignore-all-space remote gets executed.
base file:
1st line
2nd line
master file:
1st line
2nd line with substantial change
remote
On Wed, Mar 4, 2015 at 11:54 AM, Junio C Hamano gits...@pobox.com wrote:
Chris Pimlott ch...@pimlott.net writes:
folio:text chris$ git --git-dir=../.git describe --always --dirty
c0edd63-dirty
I have a feeling that this is not limited to describe at all. With
the --git-dir option, you
Jeff King p...@peff.net writes:
On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
Complexity: Was that due to replace refs? Other than that, it seemed to
be simple: max(parent generation numbers)+1.
Calculating them is simple. Caching and storage is the bigger question.
Noel Grandin n...@peralex.com writes:
On 2015-03-02 02:50 PM, Trevor Saunders wrote:
I think they solve somewhat different problems, but maybe my problem
is so specialized I should just have a wrapper around grep that
changes defaults. Trev
I'm with Trevor on this one. While I see the
Am 23.02.2015 um 20:30 schrieb René Scharfe:
Am 23.02.2015 um 14:58 schrieb Ulrike Fischer:
The zip contained four text files and a pdf.
The CTAN maintainers informed me that all files in the zip are
flagged as binaries and this makes it difficult for them to process
them further (they want to
From: Matthieu Moy matthieu@grenoble-inp.fr
Sent: Friday, February 20, 2015 9:39 AM
Jeff King p...@peff.net writes:
- Matthieu, who also cited time constraints
Just to clarify: last year we were co-mentoring with Ram. I ended up
having a lot of time and did most of the work (not
On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
Complexity: Was that due to replace refs? Other than that, it seemed to
be simple: max(parent generation numbers)+1.
Ben Walton bdwal...@gmail.com writes:
On Mon, Mar 2, 2015 at 8:30 PM Junio C Hamano gits...@pobox.com wrote:
The conversion looked good from a cursory view; I didn't check it
very carefully though.
Yes, because of the Solaris ABI, the Studio compiler defaults char to
signed char.
Doesn't
On 4 Mar 2015, Junio C Hamano Wrote:
Sent: March 4, 2015 5:11 PM
To: Ben Walton
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Use unsigned char to squash compiler warnings
Ben Walton bdwal...@gmail.com writes:
On Mon, Mar 2, 2015 at 8:30 PM Junio C Hamano gits...@pobox.com
wrote:
Troy Moure troy.mo...@gmail.com writes:
git rev-list --bisect --first-parent --parents HEAD --not HEAD~1
Hmm, as rev-list --bisect is not end-user facing command (it is
purely an implementation detail for git bisect) and we never call
it with --first-parent, I am not sure if it is worth
On Tue, Mar 3, 2015 at 3:43 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
This is v3 of the patch series. Thanks to Junio for his comments
about v2 [1]; I think this version addresses all of his points.
Changes since v2:
* Introduce a temporary in struct ref_lock: delete the force_write
Hello
My name is Amate Yolande a first year computer science student
from Cameroon. I would like to participate in the google summer fo
code 2015 with the Git community. I have done one of the micro project
and I hope it gets reviewed soon so I could update it. I would like to
work on the
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley philipoak...@iee.org wrote:
A possible idea is to add a date based variant of shallow clone :
'git clone --date when ...'
in the same vein as the existing depth (shallow) clone.
As food for thought:
Maybe broaden this further up to the git-ish
Sudhanshu Shekhar sudshekha...@gmail.com writes:
What should worry us even more is what the user would get when @{-1}
does not resolve to something the command can use. It would be bad
if we give an error message with @{-1} in it that the user never
typed (and may not even understand what it
Amate Yolande yolandeam...@gmail.com writes:
This is a patch for my work on one of the micro projects, as I intend
to apply for the Google Summer of Code 2015 under the Git community.
This patch gives the user the oppotunity to specify configuration
options for some commonly used
On Wed, Mar 4, 2015 at 11:10 AM, Shawn Pearce spea...@spearce.org wrote:
On Wed, Mar 4, 2015 at 4:05 AM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Mar 4, 2015 at 11:27 AM, Shawn Pearce spea...@spearce.org wrote:
Let me go on a different tangent a bit from the current protocol.
Hi
http://newmajorityopportunity.org/interest.php?action=6azpd6cuw9fb2
wb...@aol.com
Sent from my iPhone
--
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: Stefan Beller sbel...@google.com
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley philipoak...@iee.org
wrote:
A possible idea is to add a date based variant of shallow clone :
'git clone --date when ...'
in the same vein as the existing depth (shallow) clone.
As food for thought:
Junio C Hamano gits...@pobox.com writes:
+versionsort.prereleaseSuffix::
+When version sort is used in linkgit:git-tag[1], prerelease
+tags (e.g. 1.0-rc1) may appear after the main release
+1.0. By specifying the suffix -rc in this variable,
+1.0-rc1 will appear before 1.0.
This is a patch for my work on one of the micro projects, as I intend
to apply for the Google Summer of Code 2015 under the Git community.
This patch gives the user the oppotunity to specify configuration
options for some commonly used command-line options for exampel:
git config
On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley philipoak...@iee.org wrote:
git clone --since 2.weeks.ago url
git clone --since v2.10 url
The use of --since instead of --date would be an equally valid way of
spelling the option (coders choice;-)
I think it is a demonstration of poor
On 03/05/2015 02:28 AM, Junio C Hamano wrote:
Karthik Nayak karthik@gmail.com writes:
add sha1_object_info_literally() which is to be used when
the literally option is given to get the type of object
and print it, using sha1_object_info_extended().
add unpack_sha1_header_literally()
On Thu, Mar 5, 2015 at 6:55 AM, Stefan Beller sbel...@google.com wrote:
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley philipoak...@iee.org wrote:
A possible idea is to add a date based variant of shallow clone :
'git clone --date when ...'
in the same vein as the existing depth (shallow)
René Scharfe l@web.de writes:
No sign-off, yet, because I'm not sure we really need another option.
E.g. --text=all doesn't seem to be actually useful, but it was easy to
implement. Info-ZIP's zip always creates archives like --text=auto
does, so perhaps we should make that our default
On Wed, Mar 4, 2015 at 6:44 PM, Junio C Hamano gits...@pobox.com wrote:
Troy Moure troy.mo...@gmail.com writes:
git rev-list --bisect --first-parent --parents HEAD --not HEAD~1
Hmm, as rev-list --bisect is not end-user facing command (it is
purely an implementation detail for git bisect) and
On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
Calculating them is simple. Caching and storage is the bigger question.
Yes, also having to handle the ones whose generation numbers haven't
been computed yet adds to the complexity.
I'm not sure it's that bad. If you cache
Jeff King p...@peff.net writes:
On Wed, Mar 04, 2015 at 12:56:10PM -0800, Junio C Hamano wrote:
As in, while working on a specific project, I sometimes just want to
exclude, for the time being, a bunch of stuff from 'git grep'.
The key word here is for the time being, though. What would
Jeff King p...@peff.net writes:
On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
This one, and $gmane/264101, are a few instances of this known issue
raised here recently.
If $gmane/264101 is caused by clock skew, I'd find that disturbing.
Those algorithms are supposed to
On Wed, Mar 04, 2015 at 12:56:10PM -0800, Junio C Hamano wrote:
As in, while working on a specific project, I sometimes just want to
exclude, for the time being, a bunch of stuff from 'git grep'.
The key word here is for the time being, though. What would you
do once you are done with
karthik nayak karthik@gmail.com writes:
Looks suspiciously familiar...
Yes, you suggested it.
It has a similar structure to unpack_sha1_header().
Anything wrong with it?
I don't know if there is something wrong with the code, or not, but
it wasn't mentioned in the log message at all that
On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano gits...@pobox.com wrote:
On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley philipoak...@iee.org wrote:
git clone --since 2.weeks.ago url
git clone --since v2.10 url
The use of --since instead of --date would be an equally valid way of
Stefan Beller sbel...@google.com writes:
On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano gits...@pobox.com wrote:
On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley philipoak...@iee.org wrote:
git clone --since 2.weeks.ago url
git clone --since v2.10 url
The use of --since instead of
Lasse Kliemann la...@lassekliemann.de writes:
1. Try pushing to origin/master. If it works, fine. If not, goto 2.
2. Push to the appropriate personal branch.
I wonder what happens to this user _after_ that change gets
integrated on the project side. Presumably somebody picks up the
change
Stefan Beller sbel...@google.com writes:
I cannot remember the usual option off hand to describe the revision
instead of a date.
Because log --since=date of v1.0 master and log v1.0..master
mean two completely different things, we need some way to specify
which one of these two the user wants
Hi all,
Thanks for the review. I apologize for rushing the patch out as I
wanted to get feedback on the new behavior before committing to any
more code changes. I also wanted to quickly clear any doubts that
people may have about my coding ability. (Or maybe it created more ;)
)
On Wed, Mar 4,
Dennis Kaarsemaker den...@kaarsemaker.net writes:
For the first step, I'd send a mail to this list asking people for
input,
I'd even put that as step 2. Step 1 would be: watch the list and see if
anyone is not already working on it. Hint, hint ...
--
Matthieu Moy
On Mon, Mar 02, 2015 at 02:00:09AM +0100, SZEDER Gábor wrote:
It's not just 'grep -c' but the 'test' checking its output as well.
If something goes wrong and the line count doesn't match expectations
'test' fails silently leaving the developer clueless as to what went
wrong.
On Tue, Mar 03, 2015 at 03:54:05PM -0800, Mike Botsko wrote:
Thanks, that clarifies a lot.
I only have two follow-up questions:
In your branch example, how does git determine that C/D have been
rewritten and need to be replaced with their current versions
existing upstream? In this
On Wed, Mar 4, 2015 at 4:55 AM, Anton Trunov anton.a.tru...@gmail.com wrote:
On 04/03/15 10:07, Eric Sunshine wrote:
+ echo \t\ttwo words text.txt
Use of echo \t is not portable. Either embed literal tab characters
or use printf \t.
OK.
Shouldn't it be printf \t\n for exact
Junio C Hamano venit, vidit, dixit 03.03.2015 21:06:
Michael J Gruber g...@drmicha.warpmail.net writes:
Junio C Hamano venit, vidit, dixit 02.03.2015 20:43:
Anders Kaseorg ande...@mit.edu writes:
Signed-off-by: Anders Kaseorg ande...@mit.edu
---
t/t5516-fetch-push.sh | 2 +-
1 file
On 03/03/15 23:32, Junio C Hamano wrote:
Anton Trunov anton.a.tru...@gmail.com writes:
The git-merge manual says that the ignore-space-change,
ignore-all-space, ignore-space-at-eol options preserve our version
if their version only introduces whitespace changes to a line.
So far if there
On 03/03/15 23:17, Torsten Bögershausen wrote:
On 2015-03-03 18.37, Anton Trunov wrote:
[]
Signed-off-by: Anton Trunov anton.a.trunov at gmail.com
Should we use the real email here (with the '@') ?
Didn't realize the parser for the web version mangles emails.
Will use the real email.
---
On Fri, Feb 27, 2015 at 09:01:58PM +0700, Nguyễn Thái Ngọc Duy wrote:
The current help string is about --no-exclude-standard. But git grep -h
would show --exclude-standard instead. Flip the string. See 0a93fb8
(grep: teach --untracked and --exclude-standard options - 2011-09-27)
for more info
On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:
On Thu, Feb 19, 2015 at 2:14 AM, Jeff King p...@peff.net wrote:
Where I really need help now is in the ideas page:
http://git.github.io/SoC-2015-Ideas.html
Is this too ambitious for a summer? I suspect the answer is yes, but
On Wed, Mar 04, 2015 at 04:24:58AM +0800, Paul Tan wrote:
@@ -111,8 +114,7 @@ static void remove_credential(const char *fn, struct
credential *c)
static int lookup_credential(const char *fn, struct credential *c)
{
- parse_credential_file(fn, c, print_entry, NULL);
- return
Anders Kaseorg venit, vidit, dixit 04.03.2015 10:43:
On Wed, 4 Mar 2015, Michael J Gruber wrote:
If there is no pushurl:
url will be used as the URL for fetch and as the URL for push.
if we are pushing and there is pushinsteadof for (part of) url
subsitute that within url
else if
On March 3, 2015 11:30:13 PM GMT+05:30, Junio C Hamano gits...@pobox.com
wrote:
On Tue, Mar 3, 2015 at 8:22 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Karthik Nayak karthik@gmail.com writes:
now it works like cd which silently succeeds
Missing . at end of sentence.
And lack
On Wed, 4 Mar 2015, Michael J Gruber wrote:
If there is no pushurl:
url will be used as the URL for fetch and as the URL for push.
if we are pushing and there is pushinsteadof for (part of) url
subsitute that within url
else if there is insteadof for (part of) url
substitute
On 04/03/15 10:07, Eric Sunshine wrote:
On Tue, Mar 3, 2015 at 3:17 PM, Torsten Bögershausen tbo...@web.de wrote:
On 2015-03-03 18.37, Anton Trunov wrote:
[]
Signed-off-by: Anton Trunov anton.a.trunov at gmail.com
Should we use the real email here (with the '@') ?
---
diff --git
On Fri, Feb 27, 2015 at 01:09:30AM +0100, Marc-André Lureau wrote:
It would be nice if git-add could be told to ignore whitespace
changes, wouldn't it?
According to SO, I am not the one to think so:
http://stackoverflow.com/questions/3515597/git-add-only-non-whitespace-changes
A change
On Wed, Mar 4, 2015 at 5:31 PM, Jeff King p...@peff.net wrote:
On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:
On Thu, Feb 19, 2015 at 2:14 AM, Jeff King p...@peff.net wrote:
Where I really need help now is in the ideas page:
http://git.github.io/SoC-2015-Ideas.html
Is
On 2015-03-02 02:50 PM, Trevor Saunders wrote:
I think they solve somewhat different problems, but maybe my problem is so specialized I should just have a wrapper
around grep that changes defaults. Trev
I'm with Trevor on this one. While I see the appeal of the generality of a macro solution,
On Wed, Mar 4, 2015 at 6:26 PM, Jeff King p...@peff.net wrote:
It might be nice if parseopt had a PARSE_OPT_NEGHELP option or something
to show the --no- form.
Regardless, yes it would be nice to have something like this. I think
there are places that can make use of this.
Grepping
On Wed, Mar 4, 2015 at 5:16 PM, Jeff King p...@peff.net wrote:
Hmm. If the default is --exclude-standard, then what expect people to
use is --no-exclude-standard. Would it make more sense to list that in
the -h output?
I thought about it and actually edited git-grep man page to clarify
the
On Wed, Mar 4, 2015 at 11:27 AM, Shawn Pearce spea...@spearce.org wrote:
Let me go on a different tangent a bit from the current protocol.
http://www.grpc.io/ was recently released and is built on the HTTP/2
standard. It uses protobuf as a proven extensibility mechanism.
Including a full C
On Thu, Feb 26, 2015 at 03:23:14PM +0100, Michal Hocko wrote:
The commit in the middle was ammended to have committer date in the
past.
$ git describe --contains d63972e4e4e7eda0444e56739ad09bfbc476b9bd
tag~1
but
$ git describe --contains 108a0d5972fd2e5f25b2f38cfd2fee73031ff9d3
fatal:
Junio C Hamano venit, vidit, dixit 03.03.2015 23:26:
Junio C Hamano gits...@pobox.com writes:
Michael J Gruber g...@drmicha.warpmail.net writes:
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7508-status.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git
Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:
Michael J Gruber g...@drmicha.warpmail.net writes:
+diff --git INDEX=staged-for-commit/dir1/modified
WORKTREE=not-staged-for-commit/dir1/modified
+index e69de29..d00491f 100644
+--- INDEX=staged-for-commit/dir1/modified
On Wed, Mar 04, 2015 at 06:13:32PM +0700, Duy Nguyen wrote:
On Wed, Mar 4, 2015 at 5:16 PM, Jeff King p...@peff.net wrote:
Hmm. If the default is --exclude-standard, then what expect people to
use is --no-exclude-standard. Would it make more sense to list that in
the -h output?
I
Hi,
Quoting SZEDER Gábor sze...@ira.uka.de:
Hi,
Quoting Junio C Hamano gits...@pobox.com:
SZEDER Gábor sze...@ira.uka.de writes:
@@ -412,7 +412,7 @@ __git_refs_remotes ()
__git_remotes ()
{
local i IFS=$'\n' d=$(__gitdir)
- test -d $d/remotes ls -1 $d/remotes
+ test
The __git_remotes() helper function lists the remotes from the config
file by processing the output of a 'git config' query. A simple 'git
remote' produces the exact same output, so run that instead.
Remotes under '$GIT_DIR/remotes' are still listed by running 'ls -1',
because 'git remote'
The test checks that both remotes under '$GIT_DIR/remotes' and remotes
in the config file are listed.
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
t/t9902-completion.sh | 19 +++
1 file changed, 19 insertions(+)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
Jeff King venit, vidit, dixit 04.03.2015 11:54:
On Thu, Feb 26, 2015 at 03:23:14PM +0100, Michal Hocko wrote:
The commit in the middle was ammended to have committer date in the
past.
$ git describe --contains d63972e4e4e7eda0444e56739ad09bfbc476b9bd
tag~1
but
$ git describe --contains
84 matches
Mail list logo
