probably have this in the Makefile:
RC = $(CROSS_COMPILE)windres
And then config.mak.uname should have
RCFLAGS += -O coff
> NATIVE_CRLF = YesPlease
> X = .exe
> SPARSE_FLAGS = -Wno-one-bit-signed-bitfield
--
Felipe Contreras
--
To unsubscribe from this list: send
ntion is a good change, but please mention it in the commit
> message.
That's only if you run make without -e. If somebody wants the environment to be
trusted, they should run 'make -e' in my opinion.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "u
it at least for a while.
--
Felipe Contreras
--
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
David Kastrup wrote:
> Felipe Contreras writes:
>
> > Jeremy Morton wrote:
> >>
> >> Sounds like the default behaviour of "git pull" might not be ideal if
> >> it easily causes these problems.
> >
> > It's not idea. Virtually e
Marat Radchenko wrote:
> On Mon, Apr 28, 2014 at 12:37:42PM -0500, Felipe Contreras wrote:
> > > +CC = $(CROSS_COMPILE)cc
> >
> > Nice.
>
> Actually, not. You still have to override CC because it is
> $(CROSS_COMPILE)*g*cc. Any thoughts how to handle
Jeremy Morton wrote:
> On 28/04/2014 10:17, Felipe Contreras wrote:
> >
> > I don't seem to what? I'm the one arguing for change, and I sent the
> > patches to fix this default behavior.
>
> Well maybe you should work on phrasing things better - you come acr
Jeremy Morton wrote:
> On 28/04/2014 10:01, Felipe Contreras wrote:
> > Jeremy Morton wrote:
> >> On 27/04/2014 20:33, Johan Herland wrote:
> >>> The problem is not really "less tidy commit trees" - by which I gather
> >>> you mean history
bubbles") they create more problems than they solve.
>
> Sounds like the default behaviour of "git pull" might not be ideal if it
> easily causes these problems.
It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we
have the patches to fix it
d.
[1] http://thread.gmane.org/gmane.comp.version-control.git/198587
--
Felipe Contreras
--
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
lso, you can store that information in notes.
> You can go back through the history and find "Merge branch
> 'pacman-minigame'", but how do you know which commit was the *start* of that
> branch, if they are not tagged with the branch name?
By recording the start of the b
ined to, not to mention the fact that the commit could've been moved
> since. Nothing short of tagging the commit with the branch name when the
> commit is made will definitely record the branch name at the time of
> committing.
But why do you need that information?
--
Felipe Contreras
--
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
Philip Oakley wrote:
> From: "Felipe Contreras"
> > are the bedstone of science. You can make sensible decisions based on that
> > alone, and in fact that's how most good decisions are made.
>
> At the moment we are missing the repeatable measurements,
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > So you grant that there is no reason anybody can think of why we would ever
> > want a post-update-branch?
>
> No, it only shows that you (and I) are not imaginative enough
> (and/or we didn't bother spending
Alex Davidson wrote:
> On Fri, 2014-04-25 at 20:36 -0500, Felipe Contreras wrote:
> > Jeff King wrote:
> > > If you are waiting on me, I do not have much else to say on this topic.
> > > @{publish} as specified by Felipe is not useful to me, and I would
> > > c
just @{publish} for now, I'm farily certain most people would be using
@{publish} and not @{push}, as that's what `git branch -v` would show, and it
would be closely similar to @{upstream}. Therefore it would make sense to use
@{p} for @{publish}
--
Felipe Contreras
--
To unsubscribe
I'm right. The $subject is that
git-remote-hg/bzr are ready to be moved out of contrib, that's my contention
and I don't see why would anyone think that it's not right.
> Ah well, OK, I can't resist one last retort to one point Felipe wrote:
>
> On 24.04.2014,
Jeff King wrote:
> On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:
>
> > > Maybe I was not clear in my response, so let me try again. I do _not_
> > > necessarily agree that we need to move away from the name index.
> >
> > So you agree tha
Jeff King wrote:
> On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:
>
> > I specifically said everybody agreed to "move away from the name 'index'", I
> > didn't say everybody agreed on the "staged area" although the vast ma
Jeff King wrote:
> On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:
>
> > When I say literally everbody agreed to move away from the name "index"
> > (except
> > Junio and another guy) I mean it. I even composed a list:
> >
> &g
Signed-off-by: Felipe Contreras
---
Documentation/git-stage.txt| 5 +++
builtin/stage.c| 74 ++
contrib/completion/git-completion.bash | 4 +-
3 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/Documentation/git
Synonym for --cached.
Signed-off-by: Felipe Contreras
---
Documentation/git-submodule.txt | 8 ++--
git-submodule.sh| 10 +-
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index
Synonym of --index.
Signed-off-by: Felipe Contreras
---
Documentation/git-stash.txt | 8
git-stash.sh| 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 21a01c2..5fdaa35 100644
--- a
Synonym for --index.
Signed-off-by: Felipe Contreras
---
Documentation/git-apply.txt | 5 -
builtin/apply.c | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index f605327..8c047ef 100644
--- a
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 2ec7b1a..52d83f2 100644
--- a/contrib/completion/git
dify, or not, the working directory.
So, --work (the default), doesn't cause any changes, and --no-work
enables the current --cache if used with --index.
Eventually --work might replace --cache, if these options are
standarized in the whole git toolset.
Signed-off-by: Felipe Contrer
--no-stage is synonym for --keep-index.
Signed-off-by: Felipe Contreras
---
Documentation/git-stash.txt | 6 +++---
git-stash.sh| 8 +++-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index db7e803
Synonym for --cached.
Signed-off-by: Felipe Contreras
---
Documentation/git-rm.txt | 5 -
builtin/rm.c | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index f1efc11..458880b 100644
--- a/Documentation/git
Synonym for --cached.
Signed-off-by: Felipe Contreras
---
Documentation/git-grep.txt | 5 -
builtin/grep.c | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index f837334..6ed84d7 100644
--- a
Signed-off-by: Felipe Contreras
---
Documentation/git-reset.txt | 2 +-
builtin/reset.c | 13 ++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 5cd75a8..a1419c9 100644
--- a/Documentation/git
Signed-off-by: Felipe Contreras
---
Documentation/git-reset.txt | 8
builtin/reset.c | 20
2 files changed, 28 insertions(+)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index f445cb3..5cd75a8 100644
--- a/Documentation/git
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 52d83f2..e9b793b 100644
--- a/contrib/completion/git
us discussions:
http://thread.gmane.org/gmane.comp.version-control.git/197111
http://thread.gmane.org/gmane.comp.version-control.git/166675
http://thread.gmane.org/gmane.comp.version-control.git/115666
http://thread.gmane.org/gmane.comp.version-control.git/233295
I made a summary of all the positi
Signed-off-by: Felipe Contreras
---
Documentation/git-stage.txt| 46 +
Makefile | 2 +-
builtin.h | 1 +
builtin/stage.c| 53 ++
contrib
Synonym for --cached.
Signed-off-by: Felipe Contreras
---
Documentation/git-diff.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 56fb7e5..ca2a0ed 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation
or new comers to grasp. We
> could still support old terms for a while and eventually deprecate
> them.
And that's exactly what I did in my patch series: start introducing the --stage
options along the current ones.
http://thread.gmane.org/gmane.comp.version-control.git/236127/focus=236128
guy) I mean it. I even composed a list:
http://article.gmane.org/gmane.comp.version-control.git/233469
Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed.
> or for people for whom English might not be the first language.
People whom English is not their first language also agreed &
developers ignore them.
For example the move away from the 'index' name was backed up by literally
everyone, except Junio, so it doesn't matter if the issue is documented, and
there are patches with good solutions, if Junio thinks it's not an issue; it's
ignored.
--
Felip
acknowledge these
user-interface issues, according the them the interface doesn't require any
major changes. Which goes contrary to what most of the world believes.
--
Felipe Contreras
--
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
Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index 43631b4..fd085e1 100644
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -248,7 +248,7 @@ pick
Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> > If no action-name is specified, nothing is done.
>
> Why? Is it because git-rebase implements its own notes-copy-on-rewrite logic?
Yes, and `git rebase` uses `git cherry-pick`.
--
Felipe Contreras
--
To unsubscribe from
Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> > So that we can load and store rewrites, as well as other operations on a
> > list of rewritten commits.
>
> Please elaborate. Explain why this code shouldn't go in sequencer.c.
Isn't it obvious? Because s
Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> > @@ -635,9 +637,10 @@ static int do_pick_commit(struct commit *commit,
> > struct replay_opts *opts)
> > }
> >
> > if (opts->skip_empty && is_index_unchanged() == 1) {
>
Theodore Ts'o wrote:
> On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
> >
> > There is evidence for the claim that there won't be those problems. You have
> > absolutely no evidence there there will.
>
> It's clear that you
Andreas Krey wrote:
> On Wed, 23 Apr 2014 22:35:55 +0000, Felipe Contreras wrote:
> ...
> > Anyway, if you disagree change one of your frequently used passwords to a
> > chapter of The Lord of the Rings for a day. Let's see if you still think
> > that.
>
>
David Kastrup wrote:
> Felipe Contreras writes:
> > David Kastrup wrote:
> >> The people having to read and understand scripts written in the
> >> expectation of default aliases.
> >
> > Which are imaginary.
>
> And I prefer them to stay that way
l="), if I remember correctly, so
> > there is definitely a valid (i.e. user approved) email address.
>
> Not true. But you do get a big wall of text when you make your
> first commit without an EMAIL envvar or configured [user] section,
> including
Only if you don't hav
itely a valid (i.e. user approved) email address.
That's not true, that's only the case if you don't have a fully qualified
hostname, like 'localhost', but if you do, like localhost.redhat, then Git
assumes your email is user@localhost.redhat, and it's valid.
--
F
ne
> > defaults)
>
> But that's no worse than what we have today. What if we print what
> the defaults were, which might help encourage the user to actually run
> the "git config -e" command?
In addition we shouldn't consider user@host a valid e-mail. In the vast
Stephen Leake wrote:
> Felipe Contreras writes:
>
> >> >> I have a branch which should always be recompiled on update;
> >> >> post-update-branch would be a good place for that.
> >> >
> >> > And why would pre-update-branch not serv
David Kastrup wrote:
> Felipe Contreras writes:
>
> > James Denholm wrote:
> >> Felipe Contreras wrote:
> >> >This is a false dichotomy; there aren't just two kinds
> >> > of Git users.
> >> >
> >> > There is such a cat
Matthieu Moy wrote:
> Felipe Contreras writes:
> > Matthieu Moy wrote:
> >> Felipe Contreras writes:
> >>
> >> > Commit 26cd160 (rebase -i: use a better reflog message) tried to produce
> >> > a better reflog message, however, it
James Denholm wrote:
> Felipe Contreras wrote:
> >This is a false dichotomy; there aren't just two kinds
> > of Git users.
> >
> > There is such a category of Git users who are not
> > fresh-out-of-the-boat, yet not power users either.
>
> Oh, I di
James Denholm wrote:
> Felipe Contreras wrote:
> > It is when they start to use Git seriously and type them a lot.
>
> Felipe, I think you refute your own point here, because people _learning_ git
> aren't power-users. They might be one day, but not that day. If power-users
David Lang wrote:
> On Wed, 23 Apr 2014, Felipe Contreras wrote:
>
> > David Lang wrote:
> >> agreed, of all the things that people complain about regarding learning
> >> git,
> >> the fact that the commands are words instead of cryptic 2 letter
> >&
Hi,
Sorry it took too long to reply to this.
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >> Junio C Hamano writes:
> >> > Felipe Contreras writes:
> >
> >> But it does not have to stay that way. In order to
nd to be far more about how there are inconsistancies
> between commands, or they don't understand what's happening.
Yes, but you don't see anybody trying to improve those, do you?
This is low-hanging fruit we can actually change.
--
Felipe Contreras
--
To unsubscribe
David Kastrup wrote:
> Felipe Contreras writes:
>
> > Theodore Ts'o wrote:
> >
> >> This is especially true for commands which might not be used as often
> >> -- e.g., "rebase", and for commands where the meaning of "git commit"
>
t; name = <>
> email = <>
> [alias]
> co = checkout
> lg = log --oneline
>
> which can serve as an example the user can then tweak, without
> giving any false impression that "co" is any more spe
Signed-off-by: Felipe Contreras
---
Documentation/git-cherry-pick.txt | 6 +-
Documentation/git-revert.txt | 6 +-
builtin/revert.c | 1 +
sequencer.c | 11 +++
sequencer.h | 1 +
5 files changed, 19 insertions
And use struct rewrite.
Signed-off-by: Felipe Contreras
---
builtin/commit.c | 38 +-
rewrite.c| 32
rewrite.h| 1 +
3 files changed, 38 insertions(+), 33 deletions(-)
diff --git a/builtin/commit.c b/builtin
So it can be used by other tools (e.g. git rebase), and the right action
is passed to the hooks and notes rewrite stuff.
Signed-off-by: Felipe Contreras
---
builtin/revert.c | 2 ++
sequencer.c | 4
sequencer.h | 2 ++
3 files changed, 8 insertions(+)
diff --git a/builtin
If no action-name is specified, nothing is done.
Signed-off-by: Felipe Contreras
---
Documentation/config.txt | 9 -
Documentation/githooks.txt | 8
git-rebase--interactive.sh | 4 ++--
sequencer.c| 28 +++-
t/t3512
Will be useful for the next commits.
Signed-off-by: Felipe Contreras
---
sequencer.c | 22 +-
sequencer.h | 1 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index a258627..426fddd 100644
--- a/sequencer.c
+++ b/sequencer.c
Akin to 'am --skip' and 'rebase --skip'.
Signed-off-by: Felipe Contreras
---
Documentation/git-cherry-pick.txt | 1 +
Documentation/git-revert.txt | 1 +
Documentation/sequencer.txt | 3 +++
builtin/revert.c | 6 ++
sequencer.c
Signed-off-by: Felipe Contreras
---
sequencer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 426fddd..fc0dd04 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1056,7 +1056,7 @@ static int continue_single_pick(void)
return
Pretty much what it says on the tin.
Signed-off-by: Felipe Contreras
---
Documentation/git-cherry-pick.txt | 3 +++
builtin/revert.c| 2 ++
sequencer.c | 6 ++
sequencer.h | 1 +
t/t3508-cherry-pick-many-commits.sh
And use it on commit.c.
Signed-off-by: Felipe Contreras
---
builtin/commit.c | 8 +---
rewrite.c| 18 ++
rewrite.h| 1 +
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index ea42f22..b5287d6 100644
--- a
Signed-off-by: Felipe Contreras
---
sequencer.c | 10 +-
t/t3504-cherry-pick-rerere.sh | 39 +++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index c01ad08..a258627 100644
--- a/sequencer.c
Hi,
In the process of revamping 'git rebase' I found many areas of improvments in
`git cherry-pick`, here are the patches to improve the situation.
These were prettuch sent before already, but this time I dropped the second
part of the series to improve 'git rebase'.
So that we can load and store rewrites, as well as other operations on a
list of rewritten commits.
Signed-off-by: Felipe Contreras
---
Makefile | 2 ++
rewrite.c | 71 +++
rewrite.h | 18
3 files changed, 91
Signed-off-by: Felipe Contreras
---
sequencer.c | 2 +-
t/t3510-cherry-pick-sequence.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 90cac7b..c94942a 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -662,7 +662,7
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> >> >> I have a branch which should always be recompiled on update;
> >> >> post-update-branch would be a good place for that.
> >> >
> >> > And why would pre-update-branch not serv
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >> Felipe Contreras writes:
> >>
> >> > ... there are _already_ hooks without pre/post.
> >>
> >> Like commit-msg? Yes, it would have been nicer if it we
Max Horn wrote:
> On 23.04.2014, at 22:54, Felipe Contreras wrote:
> > Max Horn wrote:
> >> On 21.04.2014, at 22:37, Felipe Contreras
> >> wrote:
> >>
> >>> The remote-helpers in contrib/remote-helpers have proved to work, be
> >>>
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >> Felipe Contreras writes:
> >>
> >> > This hook is invoked before a branch is updated, either when a branch is
> >> > created or updated with 'git
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > ... there are _already_ hooks without pre/post.
>
> Like commit-msg? Yes, it would have been nicer if it were named
> verify-commit-message or something.
No it wouldn't. I can use the commit-msg hook to change
Matthieu Moy wrote:
> Felipe Contreras writes:
>
> > Commit 26cd160 (rebase -i: use a better reflog message) tried to produce
> > a better reflog message, however, it seems a statement was introduced by
> > mistake.
> >
> > 'comment_for_reflog start
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Signed-off-by: Felipe Contreras
>
> Why is this a good change?
When a hook is called from a command without NEED_WORK_TREE, GIT_DIR is not set
(e.g. git branch).
> How does it prevent existing hook script
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > This hook is invoked before a branch is updated, either when a branch is
> > created or updated with 'git branch', or when it's rebased with 'git
> > rebase'. It receives three parameters; th
Junio C Hamano wrote:
> Robert Dailey writes:
>
> [Administrivia: because people read from top to bottom / why is it
> bad to top-post? / please do not top-post.]
https://en.wikipedia.org/wiki/Posting_style
--
Felipe Contreras
--
To unsubscribe from this list: send the line &quo
y
reported, and there's no easy way to fix this. My proposal would be to have
some sort of branch mapping mechanism in fast-import, but hardly something that
should prevent the move out of contrib.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" i
Max Horn wrote:
> On 21.04.2014, at 22:37, Felipe Contreras wrote:
>
> > The remote-helpers in contrib/remote-helpers have proved to work, be
> > reliable, and stable. It's time to move them out of contrib, and be
> > distributed by default.
>
> Really? Whil
It is what the clients of this library expect.
Signed-off-by: Felipe Contreras
---
git-sh-setup.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 5f28b32..fb0362f 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -346,6 +346,7 @@ then
Signed-off-by: Felipe Contreras
---
run-command.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/run-command.c b/run-command.c
index 75abc47..8e188f6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -765,12 +765,29 @@ int run_hook_ve(const char
to deny the branch update.
It can be used to verify the validity of branch names, and also to keep
track of the origin point of a branch, which is otherwise not possible
to find out [1].
[1] http://thread.gmane.org/gmane.comp.version-control.git/198587
Signed-off-by: Felipe Contreras
---
D
s not always set, so the hooks (all
of them) get confused.
Too many changes since v1 to list them all.
Felipe Contreras (3):
sh-setup: export GIT_DIR
run-command: make sure hooks have always GIT_DIR
Add 'update-branch' hook
Documentation/githooks.txt| 15
Stephen Leake wrote:
> Felipe Contreras writes:
>
> > Stephen Leake wrote:
> >> Felipe Contreras writes:
> >>
> >> > Ilya Bobyr wrote:
> >> >> On 4/21/2014 2:17 PM, Felipe Contreras wrote:
> >> >> > Ilya Bobyr wrote:
Commit 26cd160 (rebase -i: use a better reflog message) tried to produce
a better reflog message, however, it seems a statement was introduced by
mistake.
'comment_for_reflog start' basically overides the GIT_REFLOG_ACTION we
just set.
Signed-off-by: Felipe Contreras
---
Theodore Ts'o wrote:
> On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
> > > I am not fundamentally opposed. I just do not think it would add
> > > much value to new people at this point, and it will actively hurt
> > > if we shoved barely
Matthieu Moy wrote:
> Felipe Contreras writes:
>
> > Why is not material for v2.0? Because you say so? Are you going to wait
> > another
> > ten years to introduce this to v3.0?
>
> There's no need to wait for a 3.0 to introduce this. If these would
> be
ment these "aliases" would result in a very
> useful addition to the system, even if done after careful thought.
The fact that you are not optimistic about it doesn't mean it's impossible.
> In any case, this definitely is not a 2.0 material. I agree that it
Ilya Bobyr wrote:
> On 4/22/2014 9:31 AM, Felipe Contreras wrote:
> > Stephen Leake wrote:
> >> Felipe Contreras writes:
> >>> Yes, there a reason for the existance of those hooks. Now tell me why
> >>> would
> >>> anybody use post-update-br
Stephen Leake wrote:
> Felipe Contreras writes:
>
> > Ilya Bobyr wrote:
> >> On 4/21/2014 2:17 PM, Felipe Contreras wrote:
> >> > Ilya Bobyr wrote:
> >> >
> >> >> Also, most have names that start with either "pre-" or
Ilya Bobyr wrote:
> On 4/21/2014 1:49 PM, Felipe Contreras wrote:
> > Ilya Bobyr wrote:
> >> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> >>> This hook is invoked whenever a branch is updated, either when a branch
> >>> is created or updated with &#
Ilya Bobyr wrote:
> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> > [...]
> >
> > diff --git a/branch.c b/branch.c
> > index 660097b..c2058d1 100644
> > --- a/branch.c
> > +++ b/branch.c
> > @@ -4,6 +4,7 @@
> > #include "refs.h"
&g
Marat Radchenko wrote:
> On Mon, Apr 21, 2014 at 07:06:24PM -0500, Felipe Contreras wrote:
> > I managed to fix all the errors, some apply to newer mingw, regardless of
> > 32 or
> > 64, others are specific to 64-bit. It's all hacky and I haven't checked if
&
cally? We can have a config key to turn
> it off, but if git diff is colored, then it could be on by default.
Having so many tools that should be rewritten to C, I don't see why anybody
should spent time rewriting scripts that are not part of the core and for the
most part do their job already
Johannes Schindelin wrote:
> On Mon, 21 Apr 2014, Felipe Contreras wrote:
> > Johannes Schindelin wrote:
> > > Now, clearly you have all the motivation that is needed to get 64-bit
> > > builds of Git for Windows going, and all the motivation required to make
> >
Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
> wrote:
>
> >> The problem is that between "git rm" and "git mv", if we default "git
> >> cp" to mean "cherry-pick" there could easily be user confu
een a time to add default
aliases after v1.0 it's certainly v2.0.
Our future users who might have not touched Git yet would certainly welcome
this.
[1] http://article.gmane.org/gmane.comp.version-control.git/165735
--
Felipe Contreras
--
To unsubscribe from this list: send the line "
401 - 500 of 3330 matches
Mail list logo
