On Wed, Apr 24, 2013 at 7:48 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>>> But P is a commit(/merge with two parents), not a blob. Can we have trees
>>> pointing to commits instead of blobs ?
>>
>> Sort of. We do so when recording submodules in regular git trees.
>
> You are using notes
Thanks.
--
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
Johan Herland writes:
>> But P is a commit(/merge with two parents), not a blob. Can we have trees
>> pointing to commits instead of blobs ?
>
> Sort of. We do so when recording submodules in regular git trees.
You are using notes to maintain reachability, aren't you? Because
commit objects tha
ESR> Ilya Basin :
>> For new branches the 'from' command can refer the common ancestor in
>> an existing branch. For example:
>>
>> /--E thebranch
>> /
>> A---B---C---D master
>>
>> Commit E is newer than D; we already imported D; thebranch is new.
>> Instead of:
>>
"ไฟใต้ ไม่จัดการพวก 'สวมรอย' ก่อน เห็นทีจะยากที่ใต้จะกลับมาร่มเย็นอีกครั้ง..."
ไทยรัฐออนไลน์พยายามค้นหาข้อมูลจากคนใน
หน่วยงานระดับปฏิบัติการในพื้นที่หลายต่อหลายคน ถึงสภาพจริงที่เกิดขึ้น
โดยเฉพาะเรื่องของการข่าวว่ามันเหมือน
หรือแตกต่างไปจากที่รับทราบกันแค่ไหนอย่างไร ก็ได้คำตอบมาว่า
จริงอยู่ที่จุ
Puppet is often used with git as the mechanism to publish/distribute
the configuration. This sidesteps the not-very-scalable central Puppet
server.
But the use of git isn't sophisticated in the least. Git can help in a
few ways, IMO, and this is my initial approach at the topic:
https://groups.go
Phil Hord writes:
> When we 'git rebase $upstream', git uses 'rev-parse --verify
> $current_branch' to find ORIG_HEAD. But if $current_branch
> is ambiguous, 'rev-parse --verify' emits a warning and returns
> a SHA1 anyway. When the wrong ambiguous choice is used,
> git-rebase fails non-gracefu
On Tue, Apr 23, 2013 at 4:51 PM, Antoine Pelisse wrote:
> On Tue, Apr 23, 2013 at 8:34 AM, Johan Herland wrote:
>> On Wed, Apr 10, 2013 at 10:35 PM, Antoine Pelisse wrote:
>>> Data-structure
>>> ==
>>> We could use a note ref to store the pre-merge information. Each commit
>>> would
curl provides many options for configuring the way it negotiates an SSL
connection (with its default OpenSSL support), including ways to define
the SSL engine used, and parameters to set the format of the key and
certificate used. Unfortunately, git does not parse some of the
critical ones needed
When we 'git rebase $upstream', git uses 'rev-parse --verify
$current_branch' to find ORIG_HEAD. But if $current_branch
is ambiguous, 'rev-parse --verify' emits a warning and returns
a SHA1 anyway. When the wrong ambiguous choice is used,
git-rebase fails non-gracefully: it emits a warning about
Any update about this:
I created this simple bug test to reproduce my problem.
I tried on latest GIT, It fails.
It is really preventing me from using GitSvn.
Any help will be highly appreciated.
Let me know if you have any questions.
[GITSVN] $git --version
git version 1.8.2.GIT
[GITSVN] $git sv
On Tue, Apr 23, 2013 at 10:02 AM, Ramkumar Ramachandra
wrote:
> This new feature allows a rebase to be executed on a dirty worktree.
> It works by creating a temporary stash and storing it in
> $state_dir/autostash before the operation, and applying it after a
> successful operation. It will be r
On Tue, Apr 16, 2013 at 9:44 PM, Jeff King wrote:
> On Tue, Apr 16, 2013 at 04:13:56PM +0200, Johannes Sixt wrote:
>
>> > I'm not clear on what you are suggesting. That we protect only the main
>> > thread from recursion, or that we drop the check entirely? Or that we
>> > implement thread-local s
Ilya Basin :
> For new branches the 'from' command can refer the common ancestor in
> an existing branch. For example:
>
> /--E thebranch
> /
> A---B---C---D master
>
> Commit E is newer than D; we already imported D; thebranch is new.
> Instead of:
> from refs/he
On Tue, Apr 23, 2013 at 4:59 PM, Junio C Hamano wrote:
> Jan Weitzel writes:
>
>> Hello,
>> I have the following problem: I have 2 bare git repositories one has
>> several branches and tags.
>> If I try this in the second repository:
>> git fetch -f ../main.git refs/heads/master:refs/heads/master
On Tue, Apr 23, 2013 at 8:25 PM, Junio C Hamano wrote:
> Yup.
>
> And then we would need to add the same option to existing callers of
> "git commit" (such as "git rebase") to pass it down the callchain.
Got it.
> But stepping back a bit, I have a suspicion that your upstream
> project _only_ ca
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Both of the two topics on preparing "git add" users for the
behaviour change in Git 2.0 are in 'master'. We may want to tweak
the wording of wa
Joel Jacobson writes:
> On Tue, Apr 23, 2013 at 6:53 PM, Junio C Hamano wrote:
>> I would consider such use of "git -c key=val" a last-resort escape
>> hatch to work around broken commands that do not implement a proper
>> escape hatch designed in to help users, unless the "key" is for
>> someth
On Tue, Apr 23, 2013 at 1:49 PM, Ramkumar Ramachandra
wrote:
> My point is simple: yes, it's nice to have a big user base. We
> already do. Now, what's the point of pitching to end-users who only
> use the most basic functionality? Their inputs are likely to be
> useless (arising from misunder
[off-topic; what happened/happens to your series is entirely unrelated
to the issue]
Felipe Contreras wrote:
> Nobody knows how life began, and it doesn't matter now, what matters
> is how life evolves. It doesn't matter if the chicken was first, or
> the egg, what matters is that if all the chick
>> But if the branch is new, but it's parent commit is already imported,
>> I guess, the only way to refer it is by its SHA-1
>> Eric, what parent information can cvsps provide for the first commit
>> in a branch, when invoked with the '-d' flag?
ESR> At the moment it doesn't provide any at all.
On Tue, Apr 23, 2013 at 6:53 PM, Junio C Hamano wrote:
> I would consider such use of "git -c key=val" a last-resort escape
> hatch to work around broken commands that do not implement a proper
> escape hatch designed in to help users, unless the "key" is for
> something very obscure and not meant
Michael J Gruber writes:
> As for the command line override:
>
> Don't we have "git -c commit.gpgsign=false" and such these days, so that
> we don't have to inflate options any more?
I would consider such use of "git -c key=val" a last-resort escape
hatch to work around broken commands that do n
Apologies for the somewhat belated reply. I've been even busier than
usual lately and am about to be traveling for a week.
Ilya Basin :
> Hi Eric.
>
> ESR> cvs-fast-export does not have incremental-import support.
> ESR> Whether git-cvs-import has it depend on which version you have
> ESR> and w
Michael Haggerty writes:
> Let me know if you would prefer that I re-roll.
Your fix-up cleanly applied to the result of applying the series up
to 16/33 and it was trivial to squash it in.
Please holler if what I push out on 'pu' in 8 hours or so looks
wrong.
Thanks.
--
To unsubscribe from thi
Junio C Hamano wrote:
> Perhaps "finish_rebase" or something?
Sure. That makes sense.
I was too busy struggling with shell code to notice these things ;)
--
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
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> +apply_autostash () {
>> +if test -f "$state_dir/autostash"
>> +then
>> +stash_sha1=$(cat "$state_dir/autostash")
>> +git stash apply $stash_sha1 2>&1 >/dev/null ||
>> +die "
>> +$(eval_gettext
Junio C Hamano wrote:
> Perhaps all of these "oops, 7/7 breaks this and that so let's work
> them around" can be avoided if the series did not store the object
> name of the stash that records the local changes as a plain text
> file inside a $dotest/ directory, and instead used a dedicated ref
> s
Ramkumar Ramachandra writes:
> Martin von Zweigbergk wrote:
>> On Tue, Apr 23, 2013 at 7:01 AM, Ramkumar Ramachandra
>> wrote:
>>> When testing if the $dotest directory exists, and if $next is greater
>>> than $last
>>
>> When can that happen? If one edits the todo?
>
> When git-rebase.sh create
Ramkumar Ramachandra writes:
> +apply_autostash () {
> + if test -f "$state_dir/autostash"
> + then
> + stash_sha1=$(cat "$state_dir/autostash")
> + git stash apply $stash_sha1 2>&1 >/dev/null ||
> + die "
> +$(eval_gettext 'Applying autostash resulted
Ramkumar Ramachandra writes:
> Some callers might want to know whether or not the worktree is clean,
> and require_clean_work_tree() has the logic for this. The current
> implementation of the function prints a message and exits if the
> worktree wasn't clean. Introduce a --quiet switch to get
Ramkumar Ramachandra writes:
> On a successful interactive rebase, git-rebase--interactive.sh
> currently cleans up and exits on its own. Instead of doing these
> two things ourselves:
>
> rm -fr "$dotest"
> git gc --auto
>
> let us return control to the caller (git-rebase.sh), to do the
On Tue, Apr 23, 2013 at 7:02 AM, Ramkumar Ramachandra
wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index cc3a9a7..9514e31 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -597,7 +597,7 @@ do_next () {
> fi
>
Ramkumar Ramachandra writes:
> Perform these two tasks:
>
> git gc --auto
> rm -fr "$dotest"
>
> only when not called with --rebasing (from git-rebase--am.sh).
> Otherwise, return control to the caller so that it can do the needful.
> The advantage of doing this is that the caller can imp
Ramkumar Ramachandra writes:
> We currently assume that, if a $dotest directory exists, an am had
> been called earlier. This assumption might get our conditional to
> match a stray $dotest directory created somewhere else,...
Hmm. that explanation sounds like that is sweeping a real issue
unde
Junio C Hamano wrote:
> So I do not see why this change could be an improvement. I would
> understand it if some future changes may have already created the
> state dir from a separate codepath (which may be an indication of a
> poor design of integrating that separate codepath, but that is a
> di
On 22/04/2013 22:49, Junio C Hamano wrote:
>
> So in addition to "have some change and there is no same parent"
> case, under _some_ condition we avoid marking a merge not worth
> showing (i.e. TREESAME) if there is any change.
>
> And the condition is !simplify_history and !simplify_merges, which
Ramkumar Ramachandra writes:
> Practically speaking, the only reason why a `mkdir $state_dir` would
> fail is because $state_dir already exists. There is no problem in
> this case, and we can proceed as usual.
That was started as a cheap way to detect and avoid running the same
rebase -i while
Martin von Zweigbergk wrote:
> On Tue, Apr 23, 2013 at 7:01 AM, Ramkumar Ramachandra
> wrote:
>> When testing if the $dotest directory exists, and if $next is greater
>> than $last
>
> When can that happen? If one edits the todo?
When git-rebase.sh creates a $dotest directory with just an autosta
Junio C Hamano wrote:
> If you need the history context (i.e. M, M^1, M^2) around it to
> interpret that additional information, isn't it essentially the same
> as storing renames in the merge commit M?
There's one big difference.
The point is that for any kind of repository composition, you're g
Martin von Zweigbergk writes:
> On Tue, Apr 23, 2013 at 7:01 AM, Ramkumar Ramachandra
> wrote:
>> When testing if the $dotest directory exists, and if $next is greater
>> than $last
>
> When can that happen? If one edits the todo?
More importantly, that condition is an unexpected error, which t
Hi list.
Things often go wrong with git svn. Often you have to try different
svn layouts and path ignores.
This is why I prefer to do the long lasting svn mirror once and then
clone the mirror to git with --use-svnsync-props. Why use this option
at all? Because without it the commits have different
Ramkumar Ramachandra writes:
> Further, this can speed up tree-rename detection greatly (in fact, I'm
> thinking the first implementation will depend on this information
> being present). I inspect M^{tree} and I want to know how it's
> composed from M^1^{tree} and M^2^{tree}. Simple. In M^{tr
On Tue, Apr 23, 2013 at 5:29 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> And I
>> have the feeling that "merge-fix/B" or "merge-fix/A" doesn't hold
>> enough information to do that accurately.
>
> Oh, you do not have to resort to feeling; these names do _not_ hold
> enough informatio
Antoine Pelisse writes:
> And I
> have the feeling that "merge-fix/B" or "merge-fix/A" doesn't hold
> enough information to do that accurately.
Oh, you do not have to resort to feeling; these names do _not_ hold
enough information, period. We already know that, that was why I was
unhappy, and t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 21/04/2013 12:14, Felipe Contreras ha scritto:
> On Fri, Jan 11, 2013 at 12:48 PM, Manlio Perillo
> wrote:
>> The git-completion.bash script did not implemented full, git aware,
>> support to complete paths, for git commands that operate on files w
Michael J Gruber writes:
> Currently, "git grep" does not honor textconv settings by default.
> Make it honor them by default just like "git log --grep" does.
"git log --grep" looks for strings in the log message which never
goes through textconv filters.
Puzzled
If you meant -S/-G, it jus
On Tue, Apr 23, 2013 at 4:53 PM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> Can you solve this problem with a tree object, instead of inventing a
>> specially-formatted blob?
>
> Hmm. What problem are you guys trying to solve?
>
> [snipped..]
> And that was why I wanted to have a data st
Michael J Gruber writes:
> Currently, "git grep" does not honor any textconv filters. Demonstrate
> this in the tests.
>
> Signed-off-by: Michael J Gruber
> ---
> t/t7008-grep-binary.sh | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/t/t7008-grep-binary.sh b/t/
Michael J Gruber writes:
> When a command is supposed to use textconv filters (by default or with
> "--textconv") and none are configured then the blob is output without
> conversion; the only exception to this rule is "cat-file --textconv".
>
> Make it behave like the rest of textconv aware comm
Michael J Gruber writes:
>> Subject: Re: [PATCHv2 2/7] show: obey --textconv for blobs
s/obey/honor/;
> Currently, "diff" and "cat-file" for blobs honor "--textconv" options
> (with the former defaulting to "--textconv" and the latter to
> "--no-textconv") whereas "show" does not honor this opt
Michael J Gruber writes:
> "git show " honors the textconv setting while "git show "
> does not. Demonstrate this in the test.
Should "git show " run textconv by default? I somehow had an
impression that people were against it during the discussion on the
previous round.
>
> Signed-off-by: Mic
Zoltan Klinger writes:
> When a rebase is interrupted by a merge conflict it could be useful to
> know how far a rebase has progressed and how many commits in total this
> rebase will apply. Teach the __git_ps1() command to display the number
> of commits so far applied and the total number of co
Łukasz Stelmach writes:
> Enable sending patches to NNTP servers (Usenet, Gmane).
> ---
>
> The patch implements support for sending messages to groups on NNTP serviers.
Cute.
A Perl guru might want to encapsulate the differences between $smtp
and $nntp codepaths into two Perl modules, but it l
Jan Weitzel writes:
> Hello,
> I have the following problem: I have 2 bare git repositories one has
> several branches and tags.
> If I try this in the second repository:
> git fetch -f ../main.git refs/heads/master:refs/heads/master
> I'm getting also tags from other branches, if I have an old
Johan Herland writes:
> Can you solve this problem with a tree object, instead of inventing a
> specially-formatted blob?
Hmm. What problem are you guys trying to solve?
I think Michael's use of a merge commit to record a merge result is
sufficient as a means to record how to recreate an evil
On Tue, Apr 23, 2013 at 8:34 AM, Johan Herland wrote:
> On Wed, Apr 10, 2013 at 10:35 PM, Antoine Pelisse wrote:
>> Data-structure
>> ==
>> We could use a note ref to store the pre-merge information. Each commit
>> would be annotated with a blob containing the list of pre-merges (one
On Tue, Apr 23, 2013 at 7:01 AM, Ramkumar Ramachandra
wrote:
> Practically speaking, the only reason why a `mkdir $state_dir` would
> fail is because $state_dir already exists.
Would we ever get to this point in the code if it already exists?
Also, I had the feeling that the check it might fail
On Tue, Apr 23, 2013 at 7:01 AM, Ramkumar Ramachandra
wrote:
> When testing if the $dotest directory exists, and if $next is greater
> than $last
When can that happen? If one edits the todo?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vg
Junio C Hamano writes:
> Joel Jacobson writes:
>
>> Signed-off-by: Joel Jacobson
>> ---
>> builtin/commit.c | 4 +++-
>
> No docs? No tests?
>
> As to the design, any regular configuration variable settings must
> be overridable from the command line for a single invocation. Please
> design an
This new feature allows a rebase to be executed on a dirty worktree.
It works by creating a temporary stash and storing it in
$state_dir/autostash before the operation, and applying it after a
successful operation. It will be removed along with the $state_dir if
the operation is aborted.
The feat
Some callers might want to know whether or not the worktree is clean,
and require_clean_work_tree() has the logic for this. The current
implementation of the function prints a message and exits if the
worktree wasn't clean. Introduce a --quiet switch to get it to report
the status of the worktree
On a successful interactive rebase, git-rebase--interactive.sh
currently cleans up and exits on its own. Instead of doing these
two things ourselves:
rm -fr "$dotest"
git gc --auto
let us return control to the caller (git-rebase.sh), to do the
needful. The advantage of doing this is tha
Perform these two tasks:
git gc --auto
rm -fr "$dotest"
only when not called with --rebasing (from git-rebase--am.sh).
Otherwise, return control to the caller so that it can do the needful.
The advantage of doing this is that the caller can implement a generic
cleanup routine (that possib
We currently assume that, if a $dotest directory exists, an am had
been called earlier. This assumption might get our conditional to
match a stray $dotest directory created somewhere else, and result in
failures down the line. So, tighten the conditional by additionally
looking for the file $dotes
Practically speaking, the only reason why a `mkdir $state_dir` would
fail is because $state_dir already exists. There is no problem in
this case, and we can proceed as usual. So, change the `mkdir` call
to `mkdir -p`, and strip the `|| die`.
Signed-off-by: Ramkumar Ramachandra
---
git-rebase--
When testing if the $dotest directory exists, and if $next is greater
than $last, the script currently executes `cat` on files that might
not exist. So, suppress the error output from `cat`.
Signed-off-by: Ramkumar Ramachandra
---
git-am.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Yes!
After struggling with shell for a couple of days, I finally managed to
achieve what I set out to do: implement a rebase.autostash without
leaking the autostash detail into specific rebases. And I'm
absolutely elated with my approach. Patches [1/7] to [6/7] make no
reference to autostash, an
Tair Sabirgaliev wrote:
> On OSX Tcl/Tk application windows are created behind all
> the applications down the stack of windows. This is very
> annoying, because once a gitk window appears, it's the
> downmost window and switching to it is pain.
>
> The patch is trivial: if we are on OSX, emulat
When a rebase is interrupted by a merge conflict it could be useful to
know how far a rebase has progressed and how many commits in total this
rebase will apply. Teach the __git_ps1() command to display the number
of commits so far applied and the total number of commits to be applied.
Below is a
On Tue, Apr 23, 2013 at 1:45 PM, Jan Weitzel wrote:
> Am Dienstag, den 23.04.2013, 13:25 +0200 schrieb Johan Herland:
>> On Tue, Apr 23, 2013 at 12:53 PM, Jan Weitzel wrote:
>> > Hello,
>> > I have the following problem: I have 2 bare git repositories one has
>> > several branches and tags.
>> >
From: Jeff King
Recently and not so recently, we made sure that log/grep type operations
use textconv filters when a userfacing diff would do the same:
ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
0508fe5
Make "grep" honor the "--textconv" option also for the object case, i.e.
when used with an argument "rev:path".
Signed-off-by: Michael J Gruber
---
builtin/grep.c | 11 ++-
object.c | 26 --
object.h | 2 ++
t/t7008-grep-binary
Currently, "git grep" does not honor textconv settings by default.
Make it honor them by default just like "git log --grep" does.
Signed-off-by: Michael J Gruber
---
Documentation/git-grep.txt | 2 +-
grep.c | 2 ++
t/t7008-grep-binary.sh | 4 ++--
3 files changed, 5 inse
When a command is supposed to use textconv filters (by default or with
"--textconv") and none are configured then the blob is output without
conversion; the only exception to this rule is "cat-file --textconv".
Make it behave like the rest of textconv aware commands.
Signed-off-by: Michael J Grub
Currently, "git grep" does not honor any textconv filters. Demonstrate
this in the tests.
Signed-off-by: Michael J Gruber
---
t/t7008-grep-binary.sh | 23 +++
1 file changed, 23 insertions(+)
diff --git a/t/t7008-grep-binary.sh b/t/t7008-grep-binary.sh
index 26f8319..126fe4c
"git show " honors the textconv setting while "git show "
does not. Demonstrate this in the test.
Signed-off-by: Michael J Gruber
---
t/t4030-diff-textconv.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index 53ec330..260e
Currently, "diff" and "cat-file" for blobs honor "--textconv" options
(with the former defaulting to "--textconv" and the latter to
"--no-textconv") whereas "show" does not honor this option, even though
it takes diff options.
Make "show" on blobs behave like "diff", i.e. honor "--textconv" by
def
Here's a reroll, with the following changes:
* Use "honor" for obey".
* Fixed the issue with --textconv and non-blobs.
* Restructured tests as per Jeff's preference.
* Added 7/ which flips the default for git grep to textconv.
Jeff King (1):
grep: allow to use textconv filters
Michael J Gru
Am Dienstag, den 23.04.2013, 13:25 +0200 schrieb Johan Herland:
> On Tue, Apr 23, 2013 at 12:53 PM, Jan Weitzel wrote:
> > Hello,
> > I have the following problem: I have 2 bare git repositories one has
> > several branches and tags.
> > If I try this in the second repository:
> > git fetch -f ../
Joel Jacobson venit, vidit, dixit 23.04.2013 02:00:
> On Tue, Apr 23, 2013 at 12:43 AM, Junio C Hamano wrote:
>> No docs? No tests?
>
> Maybe simply adding this text to git-commit.txt,
>
> The default can be changed by the 'commit.gpg-sign' configuration
> variable (see linkgit:git-config[1]).
On Tue, Apr 23, 2013 at 12:53 PM, Jan Weitzel wrote:
> Hello,
> I have the following problem: I have 2 bare git repositories one has
> several branches and tags.
> If I try this in the second repository:
> git fetch -f ../main.git refs/heads/master:refs/heads/master
> I'm getting also tags from ot
Enable sending patches to NNTP servers (Usenet, Gmane).
---
The patch implements support for sending messages to groups on NNTP serviers.
The patch does not (attempts not to) change the default behavior i.e. to use
sendmail
and/or Net::SMTP. To use NNTP one needs to configure the server (see the
Hello,
I have the following problem: I have 2 bare git repositories one has
several branches and tags.
If I try this in the second repository:
git fetch -f ../main.git refs/heads/master:refs/heads/master
I'm getting also tags from other branches, if I have an old object from
one of the other branc
real_path returns the pointer to an internal buffer, which may be
overwritten by the next real_path call. Duplicate the return value for
safety.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Apply on top of jl/submodule-mv.
Junio, I think this is the reason some tests failed when you merged
nd/mag
On 04/23/2013 12:23 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> For now I left the sleeps in t3210. Given that the problem will be
>> solved by topic jc/prune-all, building a fancier workaround into this
>> test for the old broken --expire behavior seems like a waste of time.
>> I
Matthieu Moy venit, vidit, dixit 22.04.2013 17:54:
> Jeremy Rosen writes:
>
>> some features detect if they are piping to a terminal... couldn't we do
>> something like that ?
>
> That's OK for convenience features like colors or so, but that would be
> really, really unexpected to have
>
> $ g
Junio C Hamano wrote:
> It sounds like you are repeating the same old "let's record renames
> in the commit", and in a system (not Git) where recording renames
> may make sense, you may be making sense.
>
> But we will not record renames in the commit. Time to re-read
> $gmane/217, perhaps?
Yeah,
88 matches
Mail list logo
