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
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
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
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
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
---
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:
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
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
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
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
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
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:
> 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
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:
>
> > ... 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
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
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:
> >>
> >> > ... there are _already_ hooks without pre/post.
> >>
> >> Like commit-msg? Yes, it would have been nicer if it we
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
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
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
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
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
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
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
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'.
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
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
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
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
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"
>
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
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
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
> >&
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
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
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
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
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
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
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
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
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
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.
>
>
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
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) {
>
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:
> > 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:
> > 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
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
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
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 &
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
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
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-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
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-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 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-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
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
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 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
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,
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
> I would have expected something in this style:
>
> #if defined(__x86_64__) && ! defined(lseek))
> #include
> #endif
mingw-w64 provides a 32-bit compiler as well, and it needs this fix as well
IIRC.
--
Felipe Contreras--
To unsubscribe from this list: s
James Denholm wrote:
> Felipe Contreras wrote:
> > David Kastrup wrote:
> > > It becomes easier to actually change things when communicating in a less
> > > abrasive and destructive manner.
> >
> > That would make sense if I was the only one with the
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Except that in this case virtually everyone agreed the default was wrong. I
> > already said that.
> >
> > Clarly you didn't read the relevant discussions where everyone, including
> > Lin
Jonathan Nieder wrote:
> 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
>
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > In this context James was talking about what Git should be. But the vast
> > majority agree on this issue, so that's not what's preventing change.
>
> I agree that recognition of the issue is not what
James Denholm wrote:
> Felipe Contreras wrote:
> > James Denholm wrote:
> >> It's not anybody else's job to take your patches and drizzle them in the
> >> honey of respectable discourse.
> >
> > It's nobody's job to do anything. Th
ot;
I have:
[alias]
short = show --quiet --format='%C(auto)%h (%s)%C(reset)'
--
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
be fixed later, and in
the meantime nobody gets affected negatively.
--
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
201 - 300 of 3330 matches
Mail list logo
