On Mon, May 13, 2013 at 6:32 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, May 13, 2013 at 4:23 AM, David Aguilar dav...@gmail.com wrote:
Mac OS X Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at
Updates since v8:
* Run interactive git-clean even if in dry_run mode.
-if (interactive !dry_run del_list.nr 0)
+if (interactive del_list.nr 0)
interactive_main_loop();
* Variable menu_list is not static.
(copy from global
Before introducing interactive git-clean, refactor git-clean operations
into two phases:
* hold cleaning items in del_list,
* and remove them in a separate loop at the end.
We will introduce interactive git-clean between the two phases. The
interactive git-clean will show what would be done
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
---
Documentation/config.txt | 4
builtin/clean.c |
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as color.interactive and
color.interactive.slot for command `git-add--interactive`.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
---
Add a new action for interactive git-clean: filter by pattern. When the
user chooses this action, user can input space-separated patterns (the
same syntax as gitignore), and each clean candidate that matches with
one of the patterns will be excluded from cleaning. When the user feels
it's OK,
Add a new action for interactive git-clean: ask each. It's just like
the rm -i command, that the user must confirm one by one for each
file or directory to be cleaned.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
builtin/clean.c | 36
1 file changed,
Show what would be done and the user must confirm before actually
cleaning.
Would remove ...
Would remove ...
Would remove ...
Remove [y/n]?
Press y to start cleaning, and press n if you want to abort.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
Add new section Interactive mode for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin worldhello@gmail.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-clean.txt | 65 +++--
1 file changed, 63 insertions(+), 2
Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.
User can input:
* 1,5-7 : select 1,5,6,7 items to be deleted
* * : select all items to be deleted
* -*: unselect all, nothing will be deleted
*: (empty) finish selecting, and
Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.
Please NOTE:
* Method `list_and_choose` return an array of integers, and
* it is up to you to free the allocated
Jens Lehmann jens.lehm...@web.de writes:
Am 13.05.2013 23:27, schrieb Thomas Rast:
Jens asked me at git-merge if coverage support was still available.
Turns out it is, but there were some weirdnesses. So this should fix
them. It is relly slow as you still have to run the tests one by
Thank you, this looks nice. What needs to be done that this will
eventually reach the git in my favorite distribution? Which version of
Git will this be?
Cheers
Kirill
On Sat, 2013-04-13 at 09:12 +1000, Nguyễn Thái Ngọc Duy wrote:
git checkout -- paths is usually used to restore all modified
On Tue, May 14, 2013 at 4:27 PM, Müller Kirill
kirill.muel...@ivt.baug.ethz.ch wrote:
Thank you, this looks nice. What needs to be done that this will
eventually reach the git in my favorite distribution? Which version of
Git will this be?
It'll be in the upcoming 1.8.3.
--
Duy
--
To
Hi all,
how can I make git ignore the time stamp(s) in a PDF. Two PDFs that
differ only in these time stamps should be considered identical.
Here is an example:
,
| pdfinfo some.pdf
| Title: R Graphics Output
| Creator:R
| Producer: R 2.15.1
| CreationDate: Thu Jan
The documentation of -S and -G is very sketchy. Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.
References:
52e9578 ([PATCH] Introducing software archaeologist's tool pickaxe.)
f506b8e (git log/diff: add -Gregexp that greps in the patch text)
Currently, diffcore-pickaxe reports two distinct errors for the same
user error:
$ git log --pickaxe-regex -S'\1'
fatal: invalid pickaxe regex: Invalid back reference
$ git log -G'\1' # --pickaxe-regex is implied
fatal: invalid log-grep regex: Invalid back reference
Since the
On Mon, May 13, 2013 at 10:34 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Johan Herland jo...@herland.net writes:
Obviously, I named it '%1' since it expands into the _first_ component
of the (slash-separated) shorthand.
OK, I can buy something like
Felipe Contreras felipe.contre...@gmail.com writes:
If a clone exists with the old organization (v1.8.2) it will prevent the
new shared repository organization from working, so let's remove this
repository, which is not used any more.
Signed-off-by: Felipe Contreras
Ramkumar Ramachandra artag...@gmail.com writes:
-Sstring::
- Look for differences that introduce or remove an instance of
- string. Note that this is different than the string simply
- appearing in diff output; see the 'pickaxe' entry in
- linkgit:gitdiffcore[7] for more
On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
The documentation of -S and -G is very sketchy. Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.
References:
52e9578 ([PATCH] Introducing software
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, diffcore-pickaxe reports two distinct errors for the same
user error:
$ git log --pickaxe-regex -S'\1'
fatal: invalid pickaxe regex: Invalid back reference
$ git log -G'\1' # --pickaxe-regex is implied
fatal:
On Tue, May 14, 2013 at 1:44 PM, Phil Hord phil.h...@gmail.com wrote:
On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
-Sstring::
- Look for differences that introduce or remove an instance of
- string. Note that this is different than the string
Johan Herland jo...@herland.net writes:
I think I like refs/peers/%1/heads/%* better than
refs/peers/%1/heads/%2, since the latter sort of makes me wonder
whether the 3rd, 4th, etc. components would be discarded.
Makes sense.
I am not sure why we would want refs/remotes/%1/%2 instead of
Hi all,
I tried to merge these different glossaries together (based on git de.po)
as a new wiki page [1]. You can see the diff against the current git de.po
glossary at [2]. I've also created a branch in my repository which only contains
the wiki page as a text file. This allows comments on each
Junio C Hamano wrote:
I am debating myself if it is truly easier to explain for users that
-G is a different variant of pickaxe.
Hm, I think it is the correct approach because readers of diffcore are
probably going to look at the source: it's not exactly an end-user
manpage. I've not explained
Junio C Hamano wrote:
Any time you say This means that, More precisely, etc. please
check if you can rewrite it to lose everything before them (i.e. a
vague sentence that needs to be clarified may not have to be there
at all).
Right. I thought both are necessary in this case: the first
Felipe Contreras felipe.contre...@gmail.com writes:
On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:
And others, please spend time on testing the 1.8.3-rc2 to make sure
what we are going to ship is free of embarrassing regressions.
The whole purpose of this series is
Junio C Hamano gits...@pobox.com writes:
... But now you are saying they regress
things and need 6 (in 'next') + 10 + 47 patches to fix on top, in
order not to hurt existing users?
What is going on?
Ahh, OK, I miscounted. The 10 were supposed to replace 6 and then 47
in turn are supposed
Phil Hord wrote:
References to git-log seem out of place to me here in git-diffcore. I
know it's only an example, but it seems that Git normally describes
these 'reference selectors' more generically. The generic description
may be more confusing to new users, but this patch is not the place
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Any time you say This means that, More precisely, etc. please
check if you can rewrite it to lose everything before them (i.e. a
vague sentence that needs to be clarified may not have to be there
at all).
Right. I
Phil Hord phil.h...@gmail.com writes:
Normally the pickaxe options limit the diff output to those files which
contained the changes being searched; that is, those files which
had modifications including the search string. With the --pickaxe-all
option, the diff of the entire
Junio C Hamano wrote:
I do not use zsh but with bash+readline the old tradition lnext can
be used (see stty -a output and it typically is set to ^V), i.e.
\C-v followed by \C-i should give you a literal HT.
Just looked it up: zsh has quoted-insert (^V) after which I can TAB.
Still doesn't
Felipe Contreras felipe.contre...@gmail.com writes:
On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:
Folks interested in working remote-hg, please try it out, so that we
can have a polished one soon after 1.8.3 ships (I am not saying this
round is not polished---I
Ramkumar Ramachandra wrote:
What can we do to improve the interface?
Write a better shell? Teach git gui blame to blame on arbitrary
regions instead of single lines? I'm not sure what you're asking,
mostly because I'm not sure who we is.
--
To unsubscribe from this list: send the line
Ramkumar Ramachandra artag...@gmail.com writes:
+The S kind detects filepairs whose result side and origin side
+have different number of occurrences of specified string. While
+rename detection works as usual, 'git log -S' cannot omit commits
The cannot omit feels like a confusing
On Tue, May 14, 2013 at 2:44 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Phil Hord wrote:
References to git-log seem out of place to me here in git-diffcore. I
know it's only an example, but it seems that Git normally describes
these 'reference selectors' more generically. The generic
Jonathan Nieder wrote:
Write a better shell?
Shell, editor. Both are very hard problems, and the successful
projects last many years (emacs, zsh are over 20 years old).
Teach git gui blame to blame on arbitrary
regions instead of single lines?
Or in my case: get magit to do log -S.
Should
Ramkumar Ramachandra wrote:
Should we mention in the -S documentation that temporary shell script
is the way to get multi-line input?
No, because for almost everyone it isn't.
An example in the EXAMPLES section including an aside that you might
have to hit ^V to enter a tab could be useful,
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
I do not use zsh but with bash+readline the old tradition lnext can
be used (see stty -a output and it typically is set to ^V), i.e.
\C-v followed by \C-i should give you a literal HT.
Just looked it up: zsh has
On 2013-05-09 19.18, Ramsay Jones wrote:
Torsten Bögershausen wrote:
On 2013-05-04 01.14, Junio C Hamano wrote:
Cygwin portability; both were reviewed by Jonathan, and the tip one
seems to want a bit further explanation. Needs positive report
from Cygwin 1.7 users who have been on 1.7 to
Junio C Hamano wrote:
I think what makes this paragraph unnecessarily hard to read is the
While rename works.
With that, you are implying if you rename a file as a whole without
changing the block of text you identify with the -S parameter, then
such a change is not interesting as far as
Am 14.05.2013 15:17, schrieb Andreas Leha:
Hi all,
how can I make git ignore the time stamp(s) in a PDF. Two PDFs that
differ only in these time stamps should be considered identical.
...
What I tried is a filter:
,[ ~/.gitconfig ]
| [filter pdfresetdate]
| clean =
Ramkumar Ramachandra artag...@gmail.com writes:
What I was trying to say is that it's an accidental feature
There is nothing accidental about it. It was a very conscious
design decision.
When a commit moves a file wholesale without affecting the block of
code you are interested in, you know
On Tue, May 14, 2013 at 1:21 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:
And others, please spend time on testing the 1.8.3-rc2 to make sure
what we are going to ship
Junio C Hamano wrote:
When a commit moves a file wholesale without affecting the block of
code you are interested in, you know that whole block came from the
file in the old tree at pre-rename location without looking at
anywhere else. That is why renamed but pickaxe-uninteresting
filepairs
On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
If a clone exists with the old organization (v1.8.2) it will prevent the
new shared repository organization from working, so let's remove this
repository, which is not
On Tue, May 14, 2013 at 1:59 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:
Folks interested in working remote-hg, please try it out, so that we
can have a polished one
This is a trivial cleanup, cannot cause regressions.
Felipe Contreras wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 2 +-
contrib/remote-helpers/test-hg-hg-git.sh | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
This is removing an exception check and since that exception is thrown by
check_output() but not Popen(), this doesn't change anything.
Felipe Contreras wrote:
We are not calling check_output() anymore.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
No regression here either, we simply give more power to the user.
Felipe Contreras wrote:
The user can turn this off.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 1 -
contrib/remote-helpers/test-hg-hg-git.sh | 1 +
2 files
This is simply refactoring code, functionally they are the same.
Felipe Contreras wrote:
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 24 +---
1 file changed, 13 insertions(+), 11
This is the first fix, but it's obvious this is what we want: if a user creates
a new branch with git:
% git checkout -b branches/devel
And then pushes this branch
% git push origin branches/devel
(which is the way to push new mercurial branches)
We obviously want to create a branch, but
And here is the important fix. We are essentially reverting back to the old
v1.8.2 behavior, to minimize the possibility of regressions, but in a way the
user can configure.
The cleanups before made it so this patch eas easy and simple.
And the fix before this makes it so the new default
We obviously don't want to push our fake 'master' bookmark to the remote. This
is an obvious good change.
Felipe Contreras wrote:
We skip it locally, but not for the remote, so let's do so.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg
Without this fix, the user would never ever see new bookmarks, only the ones
that (s)he initially cloned.
Felipe Contreras wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3 insertions(+)
diff --git
No-brainer; improve one test.
Felipe Contreras wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/test-hg.sh
Another no-brainer; simply shuffling some code.
Felipe Contreras wrote:
We only need to get the remote dict once.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
If a clone exists with the old organization (v1.8.2) it will prevent the
new shared repository organization from
On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
If a clone exists with the old
On Tue, May 14, 2013 at 3:50 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe
On Tue, May 14, 2013 at 12:36 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
From the point of view of Mercurial, this creates a new branch head, and
requires a forced push.
Ideally, whoever, we would want it to work just like in git; new
Did you mean s/whoever/however/ ?
branches
On Tue, May 14, 2013 at 12:36 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
The user might have then configured differently, plus, all of them will
Did you mean s/then/them/ ?
be loaded anyway later on.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
--
To unsubscribe
On Tue, May 14, 2013 at 2:57 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
I do not use zsh but with bash+readline the old tradition lnext can
be used (see stty -a output and it typically is set to ^V), i.e.
\C-v followed by \C-i should give you a literal HT.
Just
Felipe Contreras felipe.contre...@gmail.com writes:
I forgot to mention the main objective of the shared repo feature:
+ first/
* first/second/foo
* first/third/foo
* first/fourth/foo
* first/fifth/foo
* first/sixth/foo
Since in bazaar branches are repositories, we want to make it
On Tue, May 14, 2013 at 4:18 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
I forgot to mention the main objective of the shared repo feature:
+ first/
* first/second/foo
* first/third/foo
* first/fourth/foo
* first/fifth/foo
*
Felipe Contreras felipe.contre...@gmail.com writes:
No-brainer; improve one test.
In general, unless we are taking the output from commands to a file
and grepping in it, we prefer not to have --quiet (unless you are
testing the --quiet feature of the command, of course). Running the
tests
On Tue, May 14, 2013 at 4:40 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
No-brainer; improve one test.
In general, unless we are taking the output from commands to a file
and grepping in it, we prefer not to have --quiet (unless you are
Felipe Contreras felipe.contre...@gmail.com writes:
Without this fix, the user would never ever see new bookmarks, only the ones
that (s)he initially cloned.
Now, think again and realize how long it took you (the original
author) to discover issues and come up with these fixes and
explanation
Felipe Contreras felipe.contre...@gmail.com writes:
And the clone would happen either way, with or without this patch,
because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
serves is to block the new feature.
That is the answer I was trying to extract out of you (I take the
Hi,
We are using git cvsimport heavily but mostly the projects are not
using branches that much. We are also migrating our repos only once,
so there is no commits to CVS repo and no incremental imports allowed
after the migration. we have migrated more than a thousand projects
already.
we use
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
And the clone would happen either way, with or without this patch,
because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
serves is to block the new feature.
That is the answer I
On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Without this fix, the user would never ever see new bookmarks, only the ones
that (s)he initially cloned.
Now, think again and realize how long it took you (the
On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
And the clone would happen either way, with or without this patch,
because 'hg/origin/master' doesn't exist, the only purpose
On Sat, May 11, 2013 at 12:14 PM, Jeff King p...@peff.net wrote:
We have three sequential tests for for whether tracking refs
s/for for/for/
[or]
s/for for/for checking/
are updated by various fetches and pulls; the first two
should not update the ref, and the third should. Each test
depends
Eugene Sajine eugu...@gmail.com writes:
What if there are a lot of branches in the CVS repo? Is it guaranteed
to be broken after import?
Even though CVS repository can record branches in individual ,v
files, reconstructing per branch history and where the branch
happened in each changeset
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
And the clone would happen either way, with or without this patch,
On Tue, May 14, 2013 at 5:25 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Without this fix, the user would never
sorry about the MUA mangling - reply at end.
- Original Message -
From: Torsten Bögershausen tbo...@web.de
To: Ramsay Jones ram...@ramsay1.demon.co.uk
Cc: Torsten Bögershausen tbo...@web.de; Junio C Hamano
gits...@pobox.com; git@vger.kernel.org; mleved...@gmail.com;
Jonathan Nieder
On Tue, May 14, 2013 at 5:33 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
The reason for the only regression period is to avoid more
regressions. If you show me how any of the fixes I sent in this series
could potentially cause a regression,
I already said that You can see these patches are so trivially
correct is
On Tue, May 14, 2013 at 5:49 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
The reason for the only regression period is to avoid more
regressions. If you show me how any of the fixes I sent in this series
could potentially cause a regression,
On Mon, May 13, 2013 at 4:02 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Uses commit-date to sort displayed refs.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
I dig it.
I imagine it with --date-order and whatnot. But I might like it even
better if it were
Except for one nit in 1/9, the series seems to be nicely done.
--
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
Felipe Contreras felipe.contre...@gmail.com writes:
... After all, this is in the contrib area,
so if there's a time for a possible future maintainer of a core part
of git to make mistakes, it would be now.
That sounds reasonable.
Incidentally, before I had to stop working in order to
Phil Hord phil.h...@gmail.com writes:
I imagine it with --date-order and whatnot.
Perhaps modeled after this one.
git for-each-ref \
--format='%(refname:short) %(subject)'
--sort='-committerdate' refs/heads/
--
To unsubscribe from this list: send the line unsubscribe git
On Tue, May 14, 2013 at 6:32 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
... After all, this is in the contrib area,
so if there's a time for a possible future maintainer of a core part
of git to make mistakes, it would be now.
That sounds
On Tue, May 14, 2013 at 3:02 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Uses commit-date to sort displayed refs.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Just had this idea and wrote it down in five minutes. The
implementation is only meant to be indicative.
2013/5/15 Junio C Hamano gits...@pobox.com:
@@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
continue; /* Yup, this one exists unmerged */
}
- /*
- * we might have removed this as part
Jonathan Nieder jrnie...@gmail.com wrote:
I last sent these patches as an RFC a year and a half or so ago[1].
Nathan seemed to like them and they still seem valid, so thought
I'd resubmit. :)
Thanks, both applied. Sorry for forgetting :x
--
To unsubscribe from this list: send the line
Tobias Schulte tobias.schu...@gliderpilot.de wrote:
This parameter is equivalent to the parameter --parents on svn cp commands
and is useful for non-standard repository layouts.
This looks useful. A few minor cosmetic issues.
+++ b/Documentation/git-svn.txt
@@ -298,6 +298,11 @@ where name
Hi,
Has there been any further progress on this. I just encountered a SEGV with
a git apply. This is the latest git version running on Ubuntu 13.04
cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION=Ubuntu 13.04
uname -a
Linux sam-mac
Hmmm nabble embed didn't provide much value there :)
http://pastebin.com/RC8mUPF3
--
View this message in context:
http://git.661346.n2.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585907.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from
Hi,
From git help grep:
--no-index
Search files in the current directory that is not managed by Git.
--untracked
In addition to searching in the tracked files in the working tree,
search also in untracked files.
From the description above I would
94 matches
Mail list logo
