. First of all, why
"integrate"? Integrate what to what? And then, why "fail"? Fail on
what circumstances? Always?
My proposal that does:
pull.mode = merge/rebase/merge-ff-only
Is way more intuitive.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "u
he runs "git pull ~bob/project", which will merge
> Bob's HEAD.
These integrators should know what they are doing, so they can do 'git
pull --merge', or better 'git config pull.mode merge', as Linus
himself suggested (or something like that).
The defaults s
On Wed, Sep 4, 2013 at 12:19 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Tue, Sep 3, 2013 at 5:59 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
>>>> On Tue, Sep 3, 2013 at 2:32 PM, Junio C Ham
do not mind doing so if there is a good reason. But I've
> yet to see any argument beyond "it is not what I like". Which to me
> argues for the status quo as the path of least resistance.
Didn't Junio already provided reasoning?
Here's more; human semantics:
C
On Sat, Sep 7, 2013 at 11:06 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 10:11:49PM -0500, Felipe Contreras wrote:
>
>> > Though I prefer the current, I can certainly live and adapt to a changed
>> > standard, and I do not mind doing so if there is a good reason. But
On Sat, Sep 7, 2013 at 11:13 PM, Felipe Contreras
wrote:
> On Sat, Sep 7, 2013 at 11:06 PM, Jeff King wrote:
>> On Sat, Sep 07, 2013 at 10:11:49PM -0500, Felipe Contreras wrote:
>>
>>> > Though I prefer the current, I can certainly live and adapt to a changed
>&g
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:
>
>> On Wed, Sep 4, 2013 at 4:25 AM, Jeff King wrote:
>>
>> > The patch in jc/pull-training-wheel talks about annoying old timers, but
>> &
On Sat, Sep 7, 2013 at 11:26 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 11:13:10PM -0500, Felipe Contreras wrote:
>
>> > If the reasoning is "cmp(actual, expect) makes more sense to humans"
>> > then I do not think it is universal.
>>
>> No.
>&
On Sat, Sep 7, 2013 at 11:56 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 10:02:59PM -0500, Felipe Contreras wrote:
>
>> 'git checkout -' works perfectly fine, and it's the closest we have to
>> my suggested test_checkout() which I think would be ideal, but I&#x
On Sat, Sep 7, 2013 at 11:43 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
>
>> > By "svn-like", I mean the people whose workflow is:
>> >
>> > $ hack hack hack
>> > $ git commit
>> &g
On Sun, Sep 8, 2013 at 12:21 AM, Jeff King wrote:
> On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:
>
>> > It's not if you understand the difference between merge-then-commit and
>> > commit-then-merge. But for a clueless user who has been told &
On Sun, Sep 8, 2013 at 1:54 AM, Jeff King wrote:
> On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:
>
>> > I think it's fine to tell them to do "git pull --merge". What I'd worry
>> > more about is somebody who is suddenly presented
On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley wrote:
> From: "Felipe Contreras"
> Sent: Sunday, September 08, 2013 3:34 AM
>
>> On Thu, Sep 5, 2013 at 3:06 AM, John Keeping wrote:
>>>
>>> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
On Sun, Sep 8, 2013 at 2:50 AM, Jeff King wrote:
> On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote:
>
>> > I think "the guy" may be git itself. For example, here is a possible
>> > session with jc/pull-training-wheel:
>> >
>> &
rebase could
work, but I don't think 'git rebase' is the right place.
--
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
On Sun, Sep 8, 2013 at 2:49 AM, Philip Oakley wrote:
> From: "Felipe Contreras"
> Sent: Sunday, September 08, 2013 2:33 AM
> [snip...]
>
>> The snapshot concept is totally orthogonal from the staging area
>> concept. Git works in snapshots, which are frozen ima
On Sun, Sep 8, 2013 at 12:26 PM, brian m. carlson
wrote:
> On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
>> On Sat, Sep 7, 2013 at 11:18 PM, Jeff King wrote:
>> > $ hack hack hack
>> > $ svn commit ;# oops, somebody else committed in the m
s a merge, got
ya'.
But why bother with yet another useless concept the user has to learn?
The user doesn't need to learn about this concept of "integration",
all the user wants is to map:
git pull --rebase
=> pull. = rebase
git pull --merge
pull. = merge
That's it. A
posal to an option like this a
long time ago:
http://article.gmane.org/gmane.comp.version-control.git/111032
--
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
mmit)
> - return 0;
> - else
> - return 1;
> + return empty_commit ? 0 : 1;
> }
Isn't it the other way around? Moreover, 'return !!empty_commit;'
would be simpler.
--
Felipe Contreras
--
To unsubscribe from this list: send th
On Sun, Sep 8, 2013 at 5:05 PM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>>
>> @@ -290,6 +294,22 @@ int cmd_reset(int argc, const char **argv, const char
>> *prefix)
>> hashcpy(sha1, tree->object.sha1);
>> }
>>
>
On Sun, Sep 8, 2013 at 10:21 AM, René Scharfe wrote:
> Am 31.08.2013 19:20, schrieb Felipe Contreras:
>
>> A summary should contain as much information that would allow me to
>> skip the commit message as possible.
>>
>> If I can't tell from the summary if I ca
, but then it wouldn't be clear what's the main purpose of
test_diff(). Primarily what we want is to check that they are the
same. The diff is secondary, and it's not actually *needed*.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscri
On Sun, Sep 8, 2013 at 12:02 AM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 11:52:10PM -0500, Felipe Contreras wrote:
>
>> > Ah, you mean "if you think that the compare function should behave like
>> > C *_cmp functions, it should be A-B". Perhaps it is simp
On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
wrote:
> On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:
>> Yeah, but the key question at hand in this discussion is; what happens
>> when 'git pull' stops working for them, and they don't know what t
On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras
wrote:
> My patches pretty much do nothing else but introduce a warning.
> Nothing is broken, nothing is changed in the test suite:
>
> http://article.gmane.org/gmane.comp.version-control.git/233669
>
> You are confusing my pro
On Sun, Sep 8, 2013 at 7:15 PM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>> Either way it doesn't matter because Junio is determined to stand
>> alone versus the rest of the world in this issue.
>
> Which is why he's the maintainer. Send in incremen
On Sun, Sep 8, 2013 at 6:45 PM, Jeff King wrote:
> On Sun, Sep 08, 2013 at 06:25:45PM -0500, Felipe Contreras wrote:
>
>> > And I do not think it is a problem. The point of the function is not to
>> > abstract away the idea of comparison. The point is to give a hook fo
omes, they know what to type without interrupting or changing their
workflow.
Signed-off-by: Felipe Contreras
---
git-pull.sh | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 580d633..1f777de 100755
--- a/git-pull.sh
+++ b/git-pull.s
ode =
merge-ff-only.
Later on this mode can be enabled by default (e.g. in v2.0).
For the full discussion you can read:
http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225305
Signed-off-by: Felipe Contreras
---
Documentation/config.txt | 8 +---
git-pull.sh
Also, deprecate --no-rebase since there's no need for it any more.
Signed-off-by: Felipe Contreras
---
Documentation/git-pull.txt | 8 ++--
git-pull.sh| 6 +-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentatio
Signed-off-by: Felipe Contreras
---
git-pull.sh | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index de57c1d..f53d193 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -48,8 +48,7 @@ if test -z "$mode"
then
Also 'branch..rebase' to 'branch..pullmode'.
This way 'pull.mode' can be set to 'merge', and the default can be
something else.
The old configurations still work, but get deprecated.
Signed-off-by: Felipe Contreras
---
Documentation/config.txt | 22 +
-ff-only' is added, but not enabled by default, and
finally, a warning is added so the users will know what to do when the new
mode is indeed enabled by default.
Felipe Contreras (5):
pull: rename pull.rename to pull.mode
pull: refactor $rebase variable into $mode
pull: add --merge option
On Sun, Sep 8, 2013 at 8:23 PM, Felipe Contreras
wrote:
> To prepare our uses for the upcoming changes we should warn them and let
> them know that they will need to specify a merge or a rebase in the
> future (when a non-fast-forward situation arises). Also, let them know
> we fall
#x27;HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras
Signed-of
Felipe Contreras (2):
sha1-name: pass len argument to interpret_branch_name()
Add new @ shortcut for HEAD
Documentation/git-check-ref-format.txt | 2 ++
Documentation/revisions.txt| 3 +++
cache.h| 2 +-
refs.c
rgument is passed.
So let's do that.
Signed-off-by: Felipe Contreras
---
cache.h | 2 +-
refs.c | 2 +-
revision.c | 2 +-
sha1_name.c | 10 ++
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index 85b544f..9fbc5fa 100644
--- a/cache.
On Tue, Sep 3, 2013 at 1:50 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> diff --git a/sha1_name.c b/sha1_name.c
>> index 93197b9..b8ece6e 100644
>> --- a/sha1_name.c
>> +++ b/sha1_name.c
>> @@ -1004,6 +1004,26 @@ int get_sha1_mb(const char *name,
Felipe Contreras (2):
version-gen: cleanup
version-gen: avoid messing the version
GIT-VERSION-GEN | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
--
1.8.4-338-gefd7fa6
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
No functional changes.
Signed-off-by: Felipe Contreras
---
GIT-VERSION-GEN | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 06026ea..b0db139 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -7,21 +7,24
If the version is 'v1.8.4-rc1' that is the version, and there's no need
to change it to anything else, like 'v1.8.4.rc1'.
Signed-off-by: Felipe Contreras
---
GIT-VERSION-GEN | 1 -
1 file changed, 1 deletion(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index b0db
On Mon, Sep 9, 2013 at 12:51 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> If the version is 'v1.8.4-rc1' that is the version, and there's no need
>> to change it to anything else, like 'v1.8.4.rc1'.
>>
>> Signed-off-by: Felipe
On Mon, Sep 9, 2013 at 4:23 PM, Richard Hansen wrote:
> On 2013-09-08 21:23, Felipe Contreras wrote:
>> The old configurations still work, but get deprecated.
>
> Should some tests for the deprecated configs be added? We wouldn't want
> to accidentally break those.
Pro
git rebase
>
> See "pull.mode" in git-config(1) to suppress this message in the
> future.
And you propose to show that every single time the user does a 'git
pull'' that results in a non-fast-forward merge? Isn't that what 'git
pull --help' is for?
--
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
g on Git. What
> about all the newbies? They really won't have a foundation for
> what these two "flavors" mean.
>
> * The merge is very different from what Subversion presents as a
> default. That's a possible point in the "option
On Mon, Sep 9, 2013 at 2:18 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
>> wrote:
>>
>>> Yes, that would be me. My hesitance here is that as the one usually
>>> driving git updates (which so
.4, and Git chooses to use
v1.8.4 as a version name, that's fine because as a matter of fact,
that's the real version, since there's no actual changes on top of
that.
--
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
On Mon, Sep 9, 2013 at 6:30 PM, brian m. carlson
wrote:
> On Mon, Sep 09, 2013 at 02:00:55AM -0500, Felipe Contreras wrote:
>> Of course not. First of all, who exactly is packaging release
>> candidates nowadays? And second, why they can't they use the existing
>> tool
On Mon, Sep 9, 2013 at 9:21 PM, Jeff King wrote:
> On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote:
>
>> > These deprecation warning messages should be written to stderr, and
>> > should probably be prefixed with "WARNING: ".
>>
>> Is
But
> like I said, the case is not valid for me as I will always carry
> patches on top, and other people might feel differently about which
> tag (annotated vs. lightweight) they prefer if both point to the same
> commit.
Indeed. I prefer it the other way; annotated takes precedence.
--
F
I can suggest two options:
>
> - A: push to branch.*.merge if it's defined; otherwise push to branch> (like push.default=current)
> - B: push to regardless
Or C: introduce the concept of a publish branch to complement pushremote:
http://article.gmane.org/gmane.comp.version
On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> The problem is the newcomers, and the newcomers will most definitely
>> not activate a configuration option to tell them that they are doing
>> something potentially undesirable
er-branch' that was much faster. If I recall correctly, the trick
was avoiding 'git write-tree' which can be done if you are not using
any tree filter, but 'git filter-branch' is not that smart.
If all you want to do is prune empty commits, it should be easy to
writ
On Wed, Sep 11, 2013 at 6:38 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy
>> wrote:
>>
>>> So, you insist in asking the user to chose between rebase and merge, but
>>> you also insist th
Felipe Contreras (2):
version-gen: cleanup
version-gen: avoid messing the version
GIT-VERSION-GEN | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
--
1.8.4-338-gefd7fa6
--
To unsubscribe from this list: send the line "unsubscribe git&qu
If the version is 'v1.8.4-rc1' that is the version, and there's no need
to change it to anything else, like 'v1.8.4.rc1'.
If RedHat, or somebody else, needs a specific version, they can use the
'version' file, like everybody else.
Signed-off-by: Felipe Contrera
No functional changes.
Signed-off-by: Felipe Contreras
---
GIT-VERSION-GEN | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 06026ea..e96538d 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
On Thu, Sep 12, 2013 at 7:47 PM, Felipe Contreras
wrote:
> Indeed, I remember writing my own simplified version of 'git
> filter-branch' that was much faster. If I recall correctly, the trick
> was avoiding 'git write-tree' which can be done if you are not usin
On Fri, Sep 13, 2013 at 1:10 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> +describe () {
>> + VN=$(git describe --match "v[0-9]*" --abbrev=7 HEAD 2>/dev/null) ||
>> return 1
>> case "$VN" in
>> + *$LF*)
&
On Fri, Sep 13, 2013 at 1:16 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> If the version is 'v1.8.4-rc1' that is the version, and there's no need
>> to change it to anything else, like 'v1.8.4.rc1'.
>>
>> If RedHat, or so
Felipe Contreras (3):
version-gen: cleanup
version-gen: avoid messing the version
build: fix rpm versioning
GIT-VERSION-GEN | 36 +++-
Makefile| 2 +-
2 files changed, 20 insertions(+), 18 deletions(-)
--
1.8.4-fc
--
To unsubscribe from this list
No functional changes.
Signed-off-by: Felipe Contreras
---
GIT-VERSION-GEN | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 06026ea..e96538d 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
If the version is 'v1.8.4-rc1' that is the version, and there's no need
to change it to anything else, like 'v1.8.4.rc1'.
If RedHat, or somebody else, needs a specific version, they can use the
'version' file, like everybody else.
Signed-off-by: Felipe Contrera
ks in rpm-4.10, in older versions, a tilde would work as bad as
anything else.
Signed-off-by: Felipe Contreras
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 3588ca1..7a8bee7 100644
--- a/Makefile
+++ b/Makefile
@@ -2426,7 +2426,7 @@
'origin/master' is very clear, no need to specify the 'remotes/' prefix,
or babysit the user.
Signed-off-by: Felipe Contreras
---
Documentation/git-pull.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentatio
No functional changes.
Signed-off-by: Felipe Contreras
---
builtin/merge.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 34a6166..da9fc08 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -186,13 +186,6 @@ static int
Signed-off-by: Felipe Contreras
---
sha1_name.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sha1_name.c b/sha1_name.c
index 65ad066..9f3e340 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -343,7 +343,6 @@ static int get_short_sha1(const char *name, int len,
unsigned char *sha1
This is what the code intended.
No functional changes.
Signed-off-by: Felipe Contreras
---
t/annotate-tests.sh| 2 +-
t/t4200-rerere.sh | 2 +-
t/t9114-git-svn-dcommit-merge.sh | 2 +-
t/t9500-gitweb-standalone-no-errors.sh | 2 +-
4 files changed
Signed-off-by: Felipe Contreras
---
builtin/branch.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0836890..c5aa0ba 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -968,9 +968,8 @@ int cmd_branch(int argc, const char
Felipe Contreras (5):
branch: trivial style fix
sha1-name: trivial style cleanup
merge: simplify ff-only option
t: replace pulls with merges
pull: cleanup documentation
Documentation/git-pull.txt | 4 ++--
builtin/branch.c | 3 +--
builtin/merge.c
On Sun, Sep 15, 2013 at 6:42 AM, René Scharfe wrote:
> Am 09.09.2013 01:13, schrieb Felipe Contreras:
>
>> On Sun, Sep 8, 2013 at 10:21 AM, René Scharfe wrote:
>>>
>>> Am 31.08.2013 19:20, schrieb Felipe Contreras:
>>>
>>>> A summary should
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Signed-off-by: Felipe Contreras
---
Makefile | 5 -
gitconfig | 5 +
2 files changed, 9 insertions(+), 1 deletion(-)
create mode 100644 gitconfig
diff --git a/Makefile b/Makefile
index
So that we can specify general modes of operation, specifically, add the
'next' mode, which makes Git pre v2.0 behave as Git v2.0.
Signed-off-by: Felipe Contreras
---
builtin/add.c | 3 +++
cache.h | 6 ++
config.c | 13 +
environment.c | 1 +
4 files c
sume the import.
>
> 2) Scan the entire repository history, identify
> deleted branches and handle them upfront so that they never have
> conflicting names.
>
> Is there a better way?
Yes, support branch deletion natively:
http://mid.gmane.org/1377789808-2213-7-git-send-ema
time reading the config, and also prevent users from
> overriding these?
But we want them to be easily readable, and possibly allow
distributions to easily modify them.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
27;t even have a
predefined /etc/gitconfig, that creates more inconsistency, as
everybody's configs and aliases are very very different.
This patch would definitely make things more consistent.
--
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 Aguilar wrote:
> Felipe Contreras wrote:
> >On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar
> >wrote:
> >>>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar
> >wrote:
> >>>>
> >>>> Will this not conflict with folks that supply the
On Fri, Sep 20, 2013 at 7:44 PM, David Aguilar wrote:
> Felipe Contreras wrote:
>>David Aguilar wrote:
>>> Felipe Contreras wrote:
>>> >On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar
>>> >wrote:
>>> >>>On Wed, Sep 18, 2013 at 1:13 PM
On Sat, Sep 21, 2013 at 1:33 AM, David Aguilar wrote:
> Felipe Contreras wrote:
>>I know 'git ci' is perfectly fine shortcut to 'git commit'.
>>
>>Either way, it doesn't matter. Even if we agree that /etc/gitconfig.d
>>is what we want, or we a
So replace 'git-foo' with 'git foo'.
Signed-off-by: Felipe Contreras
---
Documentation/git-checkout.txt | 4 ++--
Documentation/git-commit.txt | 4 ++--
Documentation/git-rebase.txt | 4 ++--
Documentation/git-status.txt | 4 ++--
4 files changed, 8 insertions(+),
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Signed-off-by: Felipe Contreras
---
Documentation/git-checkout.txt | 5 +
Documentation/git-commit.txt | 5 +
Documentation/git-rebase.txt | 5 +
Documentation/git-status.txt
So that we can specify general modes of operation, specifically, add the
'next' mode, which makes Git pre v2.0 behave as Git v2.0.
Signed-off-by: Felipe Contreras
---
builtin/add.c | 13 +
cache.h | 6 ++
config.c | 13 +
environment.c | 1
There's no mention of the 'origin' default, or the fact that the
upstream tracking branch remote is used.
Signed-off-by: Felipe Contreras
---
Documentation/git-fetch.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/git-fetch.txt b/Documentation/git-
There's no need to set the default remote name beforehand, only to be
overridden later on, and causing a memory leak, we can do it after the
configuration has been handled.
Signed-off-by: Felipe Contreras
---
remote.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
Felipe Contreras (2):
fetch: add missing documentation
remote: fix trivial memory leak
Documentation/git-fetch.txt | 3 +++
remote.c| 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
--
1.8.4.2.gac946cf.dirty
--
To unsubscribe from this list: send the line
Signed-off-by: Felipe Contreras
---
builtin/symbolic-ref.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/symbolic-ref.c b/builtin/symbolic-ref.c
index f481959..71286b4 100644
--- a/builtin/symbolic-ref.c
+++ b/builtin/symbolic-ref.c
@@ -47,7 +47,7 @@ int
rrelation based on the fact that Mercurial is written in
Python.
http://adambard.com/blog/top-github-languages-for-2013-so-far/
== Conclusion ==
Ruby is an extremly powerful modern language, it features object oriented
paradigm, as well as functional, and procedural. It borrows from languages such
Signed-off-by: Felipe Contreras
---
Makefile | 4
cache.h | 2 ++
git.c| 3 +++
ruby.c | 48
4 files changed, 57 insertions(+)
create mode 100644 ruby.c
diff --git a/Makefile b/Makefile
index 3588ca1..7cbcbcb 100644
--- a/Makefile
Signed-off-by: Felipe Contreras
---
Makefile| 8 +++-
git-rb-setup.rb | 11 +++
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 git-rb-setup.rb
diff --git a/Makefile b/Makefile
index 7cbcbcb..138f9bf 100644
--- a/Makefile
+++ b/Makefile
@@ -491,6 +491,8
Purely for demonstration purposes.
Signed-off-by: Felipe Contreras
---
Makefile| 1 +
git-rb-setup.rb | 89
git-reset.rb| 223 ++
git.c | 1 -
ruby.c | 414
5
This is an example of how to start moving out of Git commands, towards
using Git's internal library.
Signed-off-by: Felipe Contreras
---
git-request-pull.rb | 8 +++-
ruby.c | 21 +
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/git-re
So that we can use for_each_ref() inside Ruby, and provide an example
script.
Signed-off-by: Felipe Contreras
---
Makefile| 1 +
git-refs.rb | 7 +++
ruby.c | 27 +++
3 files changed, 35 insertions(+)
create mode 100644 git-refs.rb
diff --git a/Makefile
Signed-off-by: Felipe Contreras
---
Makefile| 2 +-
git-rb-setup.rb | 25
git-request-pull.rb | 153 +
git-request-pull.sh | 162
ruby.c | 1 +
5 files
Ruby can do it just fine, no need for perl.
Signed-off-by: Felipe Contreras
---
git-request-pull.rb | 66 ++---
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/git-request-pull.rb b/git-request-pull.rb
index b6d0156..6a96a98 100644
On Sat, Sep 21, 2013 at 1:58 PM, Johannes Sixt wrote:
> Am 21.09.2013 13:47, schrieb Felipe Contreras:
>> diff --git a/Makefile b/Makefile
>> index 3588ca1..18081bf 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1010,7 +1010,7 @@ ifndef sysconfdir
>>
Signed-off-by: Felipe Contreras
---
alias.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/alias.c b/alias.c
index eb9f08b..9938f03 100644
--- a/alias.c
+++ b/alias.c
@@ -5,7 +5,7 @@ static char *alias_val;
static int alias_lookup_cb(const char *k, const
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Signed-off-by: Felipe Contreras
---
I still think we should ship a default /etc/gitconfig, but the project needs to
agree it's a good change, and nobody every agrees changes are good. So th
On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson
wrote:
> On Sat, Sep 21, 2013 at 01:48:08PM -0500, Felipe Contreras wrote:
>> Hi,
>>
>> It was discussed before that there was a need to replace Git scripts
>> from perl and sh that utilize the 'git' binary
David Aguilar wrote:
> Felipe Contreras wrote:
> >On Sat, Sep 21, 2013 at 1:58 PM, Johannes Sixt wrote:
> >> Am 21.09.2013 13:47, schrieb Felipe Contreras:
> >>> diff --git a/Makefile b/Makefile
> >>> index 3588ca1..18081bf 100644
> >>>
901 - 1000 of 3330 matches
Mail list logo
