* Re: Proposal: branch.<name>.remotepush
From: Jeff King @ 2013-02-08 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <7vd2wb483w.fsf@alter.siamese.dyndns.org>
On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote:
> To support a triangular arrangement well, there may need some
> thinking on what $branch@{upstream} means. The original intent of
> the upstream mode specified for "push.default" is push the result
> back to what you based your work on, but in a triangular arrangement
> that is no longer true.
I don't think that "upstream" or "simple" push settings really make
sense in such a triangular arrangement. And IMHO, that's OK. They
reflect a much simpler view of the world than git is capable of
supporting. So "simple" works OK as a default, and people can move to
"matching" (or "current", or even a custom refspec) once they have are
ready to take advantage of a more advanced topology/workflow.
We have the problem now that new users do not necessarily understand the
matching strategy, or why it is useful, and get confused. When we move
to "simple", we may be switching to a world where the early part of the
learning curve is more gentle for those users, but they eventually run
across the steeper part when they want to adjust their workflow (i.e.,
they will eventually learn about non-symmetric repo topologies because
those are part of many useful workflows).
But I think it's a good thing to push that part of the learning curve
out, because:
1. Some people may stay in the centralized view their whole lives and
never care.
2. It will make more sense to them, because they'll understand how it
fits into what they're trying to do, rather than viewing it as an
arcane and senseless default.
There may be some confusion as people hit that learning point. I won't
be surprised if we end up adding more advice.* messages in certain cases
to guide people to adjusting their push.default. But I'm just as happy
to wait until people start hitting the confusion point in practice, and
we can see more clearly when that advice should trigger, and what it
should say.
Unless you have ideas now, of course, in which case I'm happy to hear
them. :)
-Peff
^ permalink raw reply
* Re: [Request] Git export with hardlinks
From: Jeff King @ 2013-02-08 9:58 UTC (permalink / raw)
To: Thomas Koch; +Cc: git
In-Reply-To: <201302061619.07765.thomas@koch.ro>
On Wed, Feb 06, 2013 at 04:19:07PM +0100, Thomas Koch wrote:
> I'd like to script a git export command that can be given a list of already
> exported worktrees and the tree SHA1s these worktrees correspond too. The git
> export command should then for every file it wants to export lookup in the
> existing worktrees whether an identical file is already present and in that
> case hardlink to the new export location instead of writing the same file
> again.
>
> Use Case: A git based web deployment system that exports git trees to be
> served by a web server. Every new deployment is written to a new folder. After
> the export the web server should start serving new requests from the new
> folder.
>
> It might be possible that this is premature optimization. But I'd like to
> learn more Python and dulwich by hacking this.
>
> Do you have any additional thoughts or use cases about this?
If you can handle losing the generality of N deployments, you can do it
in a few lines of shell.
Let's assume for a moment that you keep two trees at any given time:
the existing tree being used, and the tree you are setting up to deploy.
To save space, you want the new deployment to reuse (via hardlinks) as
many of the files from the old deployment as possible.
So imagine you have a bare repository storing the actual data:
$ git clone --bare /some/test/repo repo.git
$ du -sh *
49M repo.git
and then you have one deployment you've set up previously by checking
out the repo contents:
$ export GIT_DIR=$PWD/repo.git
$ mkdir old
$ (cd old && GIT_WORK_TREE=$PWD git checkout HEAD)
$ du -sh *
24M old
49M repo.git
So a full checkout is 24M. For the next deploy, we'll start by asking
"cp" to duplicate the old, using hard links:
$ cp -rl old new
$ du -sh *
24M new
768K old
49M repo.git
and we use hardly any extra space (it should just be directory inodes).
And now we can ask git to make "new" look like some other commit. It
will only touch files which have changed, so the rest remain hardlinked,
and we use only a small amount of extra space:
$ (cd new && GIT_WORK_TREE=$PWD git checkout HEAD~10)
$ du -sh *
24M new
1.3M old
49M repo.git
Now you point your deployment at "new", and you are free to leave "old"
sitting around or remove it at your leisure. You save space while the
two co-exist, and you saved the I/O of copying any files from "old" to
"new".
This breaks down, of course, if you want to keep N trees around and
hard-link to whichever one has the content you want. For that you'd have
to write some custom code.
-Peff
^ permalink raw reply
* [PATCH v3] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Nguyễn Thái Ngọc Duy @ 2013-02-08 10:09 UTC (permalink / raw)
To: git
Cc: Matthieu Moy, Jonathan Niedier, Junio C Hamano,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1359870520-22644-1-git-send-email-pclouds@gmail.com>
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases?
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Keep "no branch" in all cases. Just append "rebasing/bisecting [%s]"
when applicable.
builtin/branch.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 6371bf9..26c0c3d 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -550,6 +550,48 @@ static int calc_maxwidth(struct ref_list *refs)
return w;
}
+static char *get_head_description()
+{
+ struct stat st;
+ struct strbuf sb = STRBUF_INIT;
+ struct strbuf result = STRBUF_INIT;
+ int bisect = 0;
+ int ret;
+ if (!stat(git_path("rebase-merge"), &st) && S_ISDIR(st.st_mode))
+ ret = strbuf_read_file(&sb, git_path("rebase-merge/head-name"), 0);
+ else if (!access(git_path("rebase-apply/rebasing"), F_OK))
+ ret = strbuf_read_file(&sb, git_path("rebase-apply/head-name"), 0);
+ else if (!access(git_path("BISECT_LOG"), F_OK)) {
+ ret = strbuf_read_file(&sb, git_path("BISECT_START"), 0);
+ bisect = 1;
+ } else
+ return xstrdup(_("(no branch)"));
+
+ if (ret <= 0) {
+ if (bisect)
+ return xstrdup(_("(no branch, bisecting)"));
+ else
+ return xstrdup(_("_(no branch, rebasing)"));
+ }
+
+ while (sb.len && sb.buf[sb.len - 1] == '\n')
+ strbuf_setlen(&sb, sb.len - 1);
+
+ if (bisect) {
+ unsigned char sha1[20];
+ if (!get_sha1_hex(sb.buf, sha1))
+ strbuf_addstr(&result, _("(no branch, bisecting)"));
+ else
+ strbuf_addf(&result, _("(no branch, bisecting %s)"), sb.buf);
+ } else {
+ if (!prefixcmp(sb.buf, "refs/heads/"))
+ strbuf_addf(&result, _("(no branch, rebasing %s)"), sb.buf + 11);
+ else
+ strbuf_addstr(&result, _("(no branch, rebasing)"));
+ }
+ strbuf_release(&sb);
+ return strbuf_detach(&result, NULL);
+}
static void show_detached(struct ref_list *ref_list)
{
@@ -557,7 +599,7 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit && is_descendant_of(head_commit, ref_list->with_commit)) {
struct ref_item item;
- item.name = xstrdup(_("(no branch)"));
+ item.name = get_head_description();
item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 3e0e15f..9b6f0d0 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if
cp .git/BISECT_START saved &&
test_must_fail git bisect start $HASH4 foo -- &&
git branch > branch.output &&
- test_i18ngrep "* (no branch)" branch.output > /dev/null &&
+ test_i18ngrep "* (no branch, bisecting other)" branch.output > /dev/null &&
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* Re: Proposal: branch.<name>.remotepush
From: Michael J Gruber @ 2013-02-08 10:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Ramkumar Ramachandra, Michael Schubert, Git List,
Jeff King
In-Reply-To: <7v622343uy.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> "Wait, why did the remote rewind?"
>
> Oh, I am very well aware of that glitch.
>
> "git push" has this hack to pretend as if the pusher immediately
> turned around and fetched from the remote.
>
> It shouldn't have been made to do so unconditionally; instead it
> should have been designed to give the pushee a way to optionally
> tell you "I acccept this push, but you may not see it to be updated
> to that exact value you pushed when you fetched from me right now".
>
> The hack is not my design; it was not even something I accepted
> without complaints, so I can badmouth about it all I want without
> hesitation ;-)
>
> More importantly, we could fix it if we wanted to.
And this seems to be more natural, too. It can keep the internals (the
auxiliary ref on the server side) hidden from the user.
As for the triangle remote, I really think we should clean up the
situation regarding push, pushurlinsteadof and the various different and
inconclusive output formats of "git remote" (with or without "-v", with
or without a remote name) first, before introducing yet another way to
twist things around. "git push downstream" does not hurt any kittens
(while git remote ouput does, somehwat).
Michael
^ permalink raw reply
* Re: [RFC/PATCH 4/4] grep: obey --textconv for the case rev:path
From: Michael J Gruber @ 2013-02-08 11:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git Mailing List
In-Reply-To: <7v4nho9f28.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 07.02.2013 19:03:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>>>> (cd t && git grep GET_SHA1_QUIETLY HEAD:../cache.h)
>>>> ../HEAD:../cache.h:#define GET_SHA1_QUIETLY 01
>>>
>>> Yuck.
>>
>> And even more yuck:
>>
>> (cd t && git grep --full-name GET_SHA1_QUIETLY HEAD:../cache.h)
>> HEAD:../cache.h:#define GET_SHA1_QUIETLY 01
>>
>> Someone does not expect a "rev:" to be in there, it seems ;)
>
> I think stepping outside of $(cwd) is an afterthought the code does
> not anticipate.
>
Well, we do resolve relative paths correctly, and there are even some
"chdir" in the code path. It's just that the output label is incorrect.
Michael
^ permalink raw reply
* [PATCH] Use __VA_ARGS__ for all of error's arguments
From: Matt Kraai @ 2013-02-08 15:09 UTC (permalink / raw)
To: git, Max Horn, Jeff King, Junio C Hamano; +Cc: Matt Kraai
In-Reply-To: <20130208043915.GB4525@ftbfs.org>
From: Matt Kraai <matt.kraai@amo.abbott.com>
QNX 6.3.2 uses GCC 2.95.3 by default, and GCC 2.95.3 doesn't remove the
comma if the error macro's variable argument is left out.
Instead of testing for a sufficiently recent version of GCC, make
__VA_ARGS__ match all of the arguments.
Signed-off-by: Matt Kraai <matt.kraai@amo.abbott.com>
---
git-compat-util.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index cc2abee..b7eaaa9 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -305,13 +305,13 @@ extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)))
/*
* Let callers be aware of the constant return value; this can help
- * gcc with -Wuninitialized analysis. We have to restrict this trick to
- * gcc, though, because of the variadic macro and the magic ## comma pasting
- * behavior. But since we're only trying to help gcc, anyway, it's OK; other
- * compilers will fall back to using the function as usual.
+ * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though,
+ * because some compilers may not support variadic macros. Since we're only
+ * trying to help gcc, anyway, it's OK; other compilers will fall back to
+ * using the function as usual.
*/
#if defined(__GNUC__) && ! defined(__clang__)
-#define error(fmt, ...) (error((fmt), ##__VA_ARGS__), -1)
+#define error(...) (error(__VA_ARGS__), -1)
#endif
extern void set_die_routine(NORETURN_PTR void (*routine)(const char *err, va_list params));
--
1.8.1.2.546.g90a97a4
^ permalink raw reply related
* git filter-branch --prune-empty not removing commits
From: Martijn van Oosterhout @ 2013-02-08 15:23 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]
Hoi,
Found a small issue with git filter-branch not removing empty commits
if they are the first commit in the tree. Find test script attached
and example output below.
I think the issue is in the function git_commit_non_empty_tree, which
doesn't handle this case. I think something like the following should
work:
git_commit_non_empty_tree()
{
+ if test $# = 1 && test -z "$(git ls-tree $1)" ; then
+ skip_commit "$@"
+ fi
if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
map "$3"
else
git commit-tree "$@"
fi
}
If you're wondering how I got here, it was by using git svn to import
a tree once converted by cvs2svn, which added empty commits to the svn
repo to indicate the creation of branches.
Have a nice day,
---- Test script output (note: destroys the foo subdirectory) ----
+ git version
git version 1.7.9.5
+ echo ======== Setup ========
+ git init foo
Initialized empty Git repository in /tmp/foo/.git/
+ export GIT_AUTHOR_NAME=foo
+ export GIT_AUTHOR_EMAIL=foo@example.com
+ export GIT_COMMITTER_NAME=foo
+ export GIT_COMMITTER_EMAIL=foo@example.com
+ cd foo
+ git write-tree
+ git commit-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 -m Commit 1
+ COMMIT1=1dc65b84c016320ce0599f2bd78bcbb5e532658f
+ export GIT_AUTHOR_NAME=bar
+ export GIT_AUTHOR_EMAIL=bar@example.com
+ echo Hello World
+ git add file
+ git write-tree
+ git commit-tree 34b512cb05f8b709198d18d916ea6395c237ae0d -m Commit 2
-p 1dc65b84c016320ce0599f2bd78bcbb5e532658f
+ COMMIT2=11af492decae1284cd2d27af4c5a92b4aab46510
+ git branch -f master 11af492decae1284cd2d27af4c5a92b4aab46510
+ git log master --stat
commit 11af492decae1284cd2d27af4c5a92b4aab46510
Author: bar <bar@example.com>
Date: Fri Feb 8 16:12:13 2013 +0100
Commit 2
file | 1 +
1 file changed, 1 insertion(+)
commit 1dc65b84c016320ce0599f2bd78bcbb5e532658f
Author: foo <foo@example.com>
Date: Fri Feb 8 16:12:13 2013 +0100
Commit 1
+ echo ======== Bug: filter-branch --prune-empty not working ========
+ git filter-branch --prune-empty master
Rewrite 11af492decae1284cd2d27af4c5a92b4aab46510 (2/2)
WARNING: Ref 'refs/heads/master' is unchanged
+ git log master --stat
commit 11af492decae1284cd2d27af4c5a92b4aab46510
Author: bar <bar@example.com>
Date: Fri Feb 8 16:12:13 2013 +0100
Commit 2
file | 1 +
1 file changed, 1 insertion(+)
commit 1dc65b84c016320ce0599f2bd78bcbb5e532658f
Author: foo <foo@example.com>
Date: Fri Feb 8 16:12:13 2013 +0100
Commit 1
--
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/
[-- Attachment #2: test --]
[-- Type: application/octet-stream, Size: 671 bytes --]
#!/bin/sh -x
git version
echo "======== Setup ========"
git init foo
export GIT_AUTHOR_NAME="foo"
export GIT_AUTHOR_EMAIL="foo@example.com"
export GIT_COMMITTER_NAME=$GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL
cd foo
COMMIT1=$(git commit-tree $(git write-tree) -m "Commit 1")
export GIT_AUTHOR_NAME="bar"
export GIT_AUTHOR_EMAIL="bar@example.com"
echo "Hello World" > file
git add file
COMMIT2=$(git commit-tree $(git write-tree) -m "Commit 2" -p $COMMIT1)
git branch -f master $COMMIT2
git log master --stat
echo "======== Bug: filter-branch --prune-empty not working ========"
git filter-branch --prune-empty master
git log master --stat
^ permalink raw reply
* Fwd: Git remote possible feature request
From: Javier Domingo @ 2013-02-08 15:30 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <CALZVapkxbY_sQucxznTQ-SJ6-YkxZvFH2TDjRtfL8Qsai1ZsWQ@mail.gmail.com>
Hi,
Just wanted to check if that when you add a remote with
--mirror=fetch, it means that you just want to fetch from that mirror.
Would that avoid accidentally pushing to that mirror?
I would like to be able to mark some remotes as read-only...
Thank you,
Javier Domingo
^ permalink raw reply
* Re: [PATCH] Use __VA_ARGS__ for all of error's arguments
From: Jeff King @ 2013-02-08 15:54 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, Max Horn, Junio C Hamano, Matt Kraai
In-Reply-To: <1360336168-27740-1-git-send-email-kraai@ftbfs.org>
On Fri, Feb 08, 2013 at 07:09:28AM -0800, Matt Kraai wrote:
> From: Matt Kraai <matt.kraai@amo.abbott.com>
>
> QNX 6.3.2 uses GCC 2.95.3 by default, and GCC 2.95.3 doesn't remove the
> comma if the error macro's variable argument is left out.
>
> Instead of testing for a sufficiently recent version of GCC, make
> __VA_ARGS__ match all of the arguments.
>
> [...]
>
> /*
> * Let callers be aware of the constant return value; this can help
> - * gcc with -Wuninitialized analysis. We have to restrict this trick to
> - * gcc, though, because of the variadic macro and the magic ## comma pasting
> - * behavior. But since we're only trying to help gcc, anyway, it's OK; other
> - * compilers will fall back to using the function as usual.
> + * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though,
> + * because some compilers may not support variadic macros. Since we're only
> + * trying to help gcc, anyway, it's OK; other compilers will fall back to
> + * using the function as usual.
> */
> #if defined(__GNUC__) && ! defined(__clang__)
> -#define error(fmt, ...) (error((fmt), ##__VA_ARGS__), -1)
> +#define error(...) (error(__VA_ARGS__), -1)
Acked-by: Jeff King <peff@peff.net>
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH v4] Add utf8_fprintf helper which returns correct columns
From: Torsten Bögershausen @ 2013-02-08 16:19 UTC (permalink / raw)
To: Jiang Xin
Cc: Torsten Bögershausen, Junio C Hamano,
Nguyễn Thái Ngọc Duy, Git List,
Nguyễn Thái Ngọc Duy
In-Reply-To: <CANYiYbGZEJXDjzBJa_qbQCgw9tcTMfOChNr6ANwaLvo=fB=bcQ@mail.gmail.com>
On 08.02.13 08:20, Jiang Xin wrote:
> 2013/2/8 Torsten Bögershausen <tboegi@web.de>:
>> On 08.02.13 03:10, Jiang Xin wrote:
>>> + /* If no error occurs, returns columns really required with utf8_strwidth. */
>>> + if (0 <= columns)
>>> + columns = utf8_strwidth(buf.buf);
>>> + strbuf_release(&buf);
>>> + return columns;
>>> +}
>>> +
>>
>> I don't think we handle the return code from fputs() correctly.
>>
>> Please dee below for specifications on fprintf(),
>> something like the following could do:
>>
>> int utf8_fprintf(FILE *stream, const char *format, ...)
>> {
>> struct strbuf buf = STRBUF_INIT;
>> va_list arg;
>> int columns = 0;
>>
>> va_start (arg, format);
>> strbuf_vaddf(&buf, format, arg);
>> va_end (arg);
>>
>> if (EOF != fputs(buf.buf, stream))
>> columns = utf8_strwidth(buf.buf);
>> strbuf_release(&buf);
>> return columns;
>> }
>
> As fputs() returns a non-negative number (as opposed to 0) on
> successful completion,
> Test fputs() return value as "fputs() >=0" is correct, while "fputs()
> == 0", "fputs() != 0"
> are wrong. I think it's OK, must I send a new re-roll for this?
>
> EOF is defined as (-1) in stdio.h:
>
> #define EOF (-1)
>
>> And as a side note: would fprintf_strwidth() be a better name?
>
> This is a nice candidate.
>
>
Doing a slurp(coffe) followed by a re-read,
I think we are save with the existng code.
However, I feel that the commit message can be improved,
as it fixes problems not only for CJK but e.g. european languages
(and all systems using utf-8)
>Since command usages can be translated, they may not align well especially
>when they are translated to CJK. A wrapper utf8_fprintf can help to return
>the correct columns required.
Since command usages can be translated, they may include utf-8 encoded strings,
and strlen() is different from strwidth().
A wrapper utf8_fprintf() helps to return the correct columns required.
Thanks for working on this.
^ permalink raw reply
* [PATCH] user-manual: Rewrite git-gc section for automatic packing
From: W. Trevor King @ 2013-02-08 16:43 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
This should have happened back in 2007, when `git gc` learned about
auto:
commit e9831e83e063844b90cf9e525d0003715dd8b395
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Sep 17 00:39:52 2007 -0700
git-gc --auto: add documentation.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
I'd also be happy just dropping the whole git-gc section ;).
Documentation/user-manual.txt | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5077e7c..d14e3c7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1562,17 +1562,13 @@ Ensuring good performance
-------------------------
On large repositories, Git depends on compression to keep the history
-information from taking up too much space on disk or in memory.
+information from taking up too much space on disk or in memory. Some
+git commands may automatically run linkgit:git-gc[1], so you don't
+have to worry about running it manually. However, compressing large
+repositories may take some time, so you might want to disable
+automatic comression and run it explicitly when you are not doing
+other work.
-This compression is not performed automatically. Therefore you
-should occasionally run linkgit:git-gc[1]:
-
--------------------------------------------------
-$ git gc
--------------------------------------------------
-
-to recompress the archive. This can be very time-consuming, so
-you may prefer to run `git gc` when you are not doing other work.
[[ensuring-reliability]]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* Re: git filter-branch --prune-empty not removing commits
From: Martijn van Oosterhout @ 2013-02-08 16:53 UTC (permalink / raw)
To: git
In-Reply-To: <CADWG95sHx6Z2Ukon8FAHKa1qUOj4shd4MbCwahwX++FVWJPDDg@mail.gmail.com>
On 8 February 2013 16:23, Martijn van Oosterhout <kleptog@gmail.com> wrote:
> git_commit_non_empty_tree()
> {
> + if test $# = 1 && test -z "$(git ls-tree $1)" ; then
> + skip_commit "$@"
> + fi
> if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
> map "$3"
> else
> git commit-tree "$@"
> fi
> }
This bit is a but bunk, the fi should be an else, otherwise it does nothing.
Have a nice day,
--
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/
^ permalink raw reply
* Re: [PATCH 3/4] Makefile: factor common configuration in git-default-config.mak
From: Matthieu Moy @ 2013-02-08 17:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobfv7wkl.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I really think this is going in a wrong direction. Whatever you
> happen to have chosen in this patch will be available to others,
> while whatever are left out will not be. When adding new things,
> people need to ask if it needs to be sharable or not, and the right
> answer to that question will even change over time.
My feeling is that Git's toplevel Makefile has become too large to
remain completely monolithic, and splitting is good to organize it (and
yes, splitting code into several files imply that future added code will
have to be added in the right file, but that's not very different from
splitting C code into several .c files to me). But that is another
matter, and ...
Junio C Hamano <gitster@pobox.com> writes:
> Then do something like
>
> all::
> $(MAKE) -C ../.. \
> PERL_SCRIPT=contrib/mw-to-git/git-remote-mediawiki.perl \
> build-perl-script
This ended up being very simple to implement (essentially, the Makefile
already knows how to do this, so this just means adding convenience
build-perl-script target to the toplevel), so 2 new patches follow doing
this, with a ridiculously small new version of mw-to-git/Makefile.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 17:06 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <20130208092204.GA15490@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> We have the problem now that new users do not necessarily understand the
> matching strategy, or why it is useful, and get confused. When we move
> to "simple", we may be switching to a world where the early part of the
> learning curve is more gentle for those users, but they eventually run
> across the steeper part when they want to adjust their workflow (i.e.,
> they will eventually learn about non-symmetric repo topologies because
> those are part of many useful workflows).
>
> But I think it's a good thing to push that part of the learning curve
> out, because:
>
> 1. Some people may stay in the centralized view their whole lives and
> never care.
>
> 2. It will make more sense to them, because they'll understand how it
> fits into what they're trying to do, rather than viewing it as an
> arcane and senseless default.
>
> There may be some confusion as people hit that learning point. I won't
> be surprised if we end up adding more advice.* messages in certain cases
> to guide people to adjusting their push.default. But I'm just as happy
> to wait until people start hitting the confusion point in practice, and
> we can see more clearly when that advice should trigger, and what it
> should say.
Oh, I agree with you that adding new support for triangular workflow
will not hurt the centralized folks. I was more interested about
helping the "fetch from here, push to there" people.
Centralized people do not have to configure anything for each branch
for "git push" to push their current branch to where they fetch from
and to the same name (you start building on their 'master', your
result go to their 'master', because as a centralized person, you
are part of 'them'). They have branch.$name.merge that names what
their $name branch merges with, and that is sufficient to decide to
which branch the result is to be pushed back.
With the "push.defaultTo = peff" to name what remote the "git push"
will push to, or even with the "branch.master.remotepush = peff" to
decide that per branch, would "fetch from here, push to there"
people have a way similar to what branch.$name.merge gives to the
centralized people to decide what branch is updated?
It almost seems to me that we may want to extend the semantics given
to the remote.$name.push refspecs. They are primarily for "perfect
all branches you are going to push out, and push them in one go with
'git push'" workflow, but if it is clear that you are not following
that (e.g. you are doing an equivalent of what the centralized folks
would do with "push.default = simple/upstream/current") and pushing
only the current branch, perhaps we should look at these refspecs to
see where the current branch goes?
In your case, 'refs/heads/master' would likely to go to
'refs/heads/master', and we could treat a missing remote.peff.push
an equivalent to having remote.peff.push = refs/heads/*:refs/heads/*
In a Gerrit user's case brought up by Michael Schubert in a message
earlier in the near-by subthread, 'refs/heads/frotz' would likely to
go to 'refs/for/frotz' and they can express it with something like
[remote "origin"]
url = ... ;# pushurl is the same or just s/git/ssh/;
fetch = refs/heads/*:refs/heads/*
push = refs/heads/*:refs/for/*
[push]
default = "???"
where "???" says "I push out only the currently checked-out branch;
figure out where it goes using remote.origin.push refspec".
Having to set both branch.$name.remotepush to name what remote this
branch should be pushed, and branch.$name.branchpush to name what
branch at the remote this branch should update with a push, and
doing so for each and every branch, sounds like an unnecessary
complexity.
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 17:11 UTC (permalink / raw)
To: Michael J Gruber
Cc: Jonathan Nieder, Ramkumar Ramachandra, Michael Schubert, Git List,
Jeff King
In-Reply-To: <5114D5B0.5080906@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> As for the triangle remote, I really think we should clean up the
> situation regarding push, pushurlinsteadof and the various different and
> inconclusive output formats of "git remote" (with or without "-v", with
> or without a remote name) first, before introducing yet another way to
> twist things around. "git push downstream" does not hurt any kittens
> (while git remote ouput does, somehwat).
As people tend to fetch more often than they push if they are
working on a real project where the others as a whole will be far
more productive than any single individual, I agree that keeping
"git fetch" (or "git pull") lazy by having "origin" point at where
they fetch from and be a bit more explicit in "git push" would
actually make sense.
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 17:16 UTC (permalink / raw)
To: Michael J Gruber
Cc: Jonathan Nieder, Ramkumar Ramachandra, Michael Schubert, Git List,
Jeff King
In-Reply-To: <5114D5B0.5080906@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetched from the remote.
>>
>> It shouldn't have been made to do so unconditionally; instead it
>> should have been designed to give the pushee a way to optionally
>> tell you "I acccept this push, but you may not see it to be updated
>> to that exact value you pushed when you fetched from me right now".
>>
>> The hack is not my design; it was not even something I accepted
>> without complaints, so I can badmouth about it all I want without
>> hesitation ;-)
>>
>> More importantly, we could fix it if we wanted to.
>
> And this seems to be more natural, too. It can keep the internals (the
> auxiliary ref on the server side) hidden from the user.
Fixing that misfeature to always pretend it immediately turned
around and fetched may have a different benefit, too.
A straightforward and simple solution to Ram's original problem may
be to define pushurl to point at his publishing repository after
all, and teach "git push" not to pretend it immediately fetched with
the same "fix".
[remote "origin"]
url = ... where Ram fetches and pulls from ...
pushurl = ... where Ram pushes to ...
fetch = refs/heads/*:refs/remotes/*
updateTrackOnPush = no
Then "git fetch" (or "git pull") will update the remote tracking
branches Ram fetches from, and once his topic is finished, he can
push to his publishing location, which won't touch the remote
tracking branches used to keep track of the place he fetches from.
^ permalink raw reply
* [PATCH 1/2] Makefile: make script-related rules usable from subdirectories
From: Matthieu Moy @ 2013-02-08 17:31 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <vpq4nhmbusp.fsf@grenoble-inp.fr>
Git's Makefile provides a few nice features for script build and
installation (substitute the first line with the right path, hardcode the
path to Git library, ...).
The Makefile already knows how to process files outside the toplevel
directory with e.g.
make SCRIPT_PERL=path/to/file.perl path/to/file
but we can make it simpler for callers by exposing build, install and
clean rules as .PHONY targets.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
The goal of this series is to use perl, but it is as easy to do it
with sh and python too, so I did it for them too. I tested a manual
"make -C ../../" in contrib/subtree and contrib/hg-to-git/ to check that
it actually works.
Makefile | 35 ++++++++++++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 5a2e02d..b4af30d 100644
--- a/Makefile
+++ b/Makefile
@@ -480,9 +480,38 @@ SCRIPT_PERL += git-svn.perl
SCRIPT_PYTHON += git-remote-testpy.py
SCRIPT_PYTHON += git-p4.py
-SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
- $(patsubst %.perl,%,$(SCRIPT_PERL)) \
- $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
+# Generated files for scripts
+SCRIPT_SH_GEN = $(patsubst %.sh,%,$(SCRIPT_SH))
+SCRIPT_PERL_GEN = $(patsubst %.perl,%,$(SCRIPT_PERL))
+SCRIPT_PYTHON_GEN = $(patsubst %.py,%,$(SCRIPT_PYTHON))
+
+# Individual rules to allow e.g.
+# "make -C ../.. SCRIPT_PERL=contrib/foo/bar.perl build-perl-script"
+# from subdirectories like contrib/*/
+.PHONY: build-perl-script build-sh-script build-python-script
+build-perl-script: $(SCRIPT_PERL_GEN)
+build-sh-script: $(SCRIPT_SH_GEN)
+build-python-script: $(SCRIPT_PYTHON_GEN)
+
+.PHONY: install-perl-script install-sh-script install-python-script
+install-sh-script: $(SCRIPT_SH_GEN)
+ $(INSTALL) $(SCRIPT_SH_GEN) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+install-perl-script: $(SCRIPT_PERL_GEN)
+ $(INSTALL) $(SCRIPT_PERL_GEN) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+install-python-script: $(SCRIPT_PYTHON_GEN)
+ $(INSTALL) $(SCRIPT_PYTHON_GEN) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+
+.PHONY: clean-perl-script clean-sh-script clean-python-script
+clean-sh-script:
+ $(RM) $(SCRIPT_SH_GEN)
+clean-perl-script:
+ $(RM) $(SCRIPT_PERL_GEN)
+clean-python-script:
+ $(RM) $(SCRIPT_PYTHON_GEN)
+
+SCRIPTS = $(SCRIPT_SH_GEN) \
+ $(SCRIPT_PERL_GEN) \
+ $(SCRIPT_PYTHON_GEN) \
git-instaweb
ETAGS_TARGET = TAGS
--
1.8.1.2.530.g3cc16e4.dirty
^ permalink raw reply related
* [PATCH 2/2] git-remote-mediawiki: use toplevel's Makefile
From: Matthieu Moy @ 2013-02-08 17:31 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1360344677-5962-1-git-send-email-Matthieu.Moy@imag.fr>
This makes the Makefile simpler, while providing more features, and more
consistency (the exact same rules with the exact same configuration as
Git official commands are applied with the new version).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/.gitignore | 1 +
contrib/mw-to-git/Makefile | 64 ++++++----------------
...-remote-mediawiki => git-remote-mediawiki.perl} | 0
3 files changed, 18 insertions(+), 47 deletions(-)
create mode 100644 contrib/mw-to-git/.gitignore
rewrite contrib/mw-to-git/Makefile (96%)
rename contrib/mw-to-git/{git-remote-mediawiki => git-remote-mediawiki.perl} (100%)
diff --git a/contrib/mw-to-git/.gitignore b/contrib/mw-to-git/.gitignore
new file mode 100644
index 0000000..b919655
--- /dev/null
+++ b/contrib/mw-to-git/.gitignore
@@ -0,0 +1 @@
+git-remote-mediawiki
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
dissimilarity index 96%
index 3ed728b..f149719 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -1,47 +1,17 @@
-#
-# Copyright (C) 2012
-# Charles Roussel <charles.roussel@ensimag.imag.fr>
-# Simon Cathebras <simon.cathebras@ensimag.imag.fr>
-# Julien Khayat <julien.khayat@ensimag.imag.fr>
-# Guillaume Sasdy <guillaume.sasdy@ensimag.imag.fr>
-# Simon Perrat <simon.perrat@ensimag.imag.fr>
-#
-## Build git-remote-mediawiki
-
--include ../../config.mak.autogen
--include ../../config.mak
-
-ifndef PERL_PATH
- PERL_PATH = /usr/bin/perl
-endif
-ifndef gitexecdir
- gitexecdir = $(shell git --exec-path)
-endif
-
-PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
-gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
-SCRIPT = git-remote-mediawiki
-
-.PHONY: install help doc test clean
-
-help:
- @echo 'This is the help target of the Makefile. Current configuration:'
- @echo ' gitexecdir = $(gitexecdir_SQ)'
- @echo ' PERL_PATH = $(PERL_PATH_SQ)'
- @echo 'Run "$(MAKE) install" to install $(SCRIPT) in gitexecdir'
- @echo 'Run "$(MAKE) test" to run the testsuite'
-
-install:
- sed -e '1s|#!.*/perl|#!$(PERL_PATH_SQ)|' $(SCRIPT) \
- > '$(gitexecdir_SQ)/$(SCRIPT)'
- chmod +x '$(gitexecdir)/$(SCRIPT)'
-
-doc:
- @echo 'Sorry, "make doc" is not implemented yet for $(SCRIPT)'
-
-test:
- $(MAKE) -C t/ test
-
-clean:
- $(RM) '$(gitexecdir)/$(SCRIPT)'
- $(MAKE) -C t/ clean
+#
+# Copyright (C) 2013
+# Matthieu Moy <Matthieu.Moy@imag.fr>
+#
+## Build git-remote-mediawiki
+
+SCRIPT_PERL=git-remote-mediawiki.perl
+GIT_ROOT_DIR=../..
+HERE=contrib/mw-to-git/
+
+SCRIPT_PERL_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL))
+
+all: build
+
+build install clean:
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $@-perl-script
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki.perl
similarity index 100%
rename from contrib/mw-to-git/git-remote-mediawiki
rename to contrib/mw-to-git/git-remote-mediawiki.perl
--
1.8.1.2.530.g3cc16e4.dirty
^ permalink raw reply related
* Re: [PATCH] git-mergetool: print filename when it contains %
From: Junio C Hamano @ 2013-02-08 17:32 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: git
In-Reply-To: <1360286184-14278-1-git-send-email-asheesh@asheesh.org>
Asheesh Laroia <asheesh@asheesh.org> writes:
> Before this change, if git-mergetool was invoked with regard to
Drop "before this change,"; it is clear (and it is a recommended
practice) you are first describing what problem you are addressing.
> files with a percent sign (%) in their names, it would print an
> error. For example, if you were calling mergetool on a file called
> "%2F":
>
> printf: %2F: invalid directive
>
> This changes the behavior to pass "%s" to printf as its first argument
> to avoid processing the filename as a format string.
>
> Signed-off-by: Asheesh Laroia <asheesh@asheesh.org>
> ---
Thanks.
As a follow-up to this patch, we may want to perform a systematic
audit of
$ git grep -e 'printf "[^"]*\$[^"]*"'
There is one in git-difftool-helper.sh
printf "\nViewing: '$MERGED'\n"
and mergetools/p4merge:
printf "$empty_file"
> git-mergetool.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index c50e18a..d2b9289 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -440,7 +440,7 @@ then
> fi
>
> printf "Merging:\n"
> -printf "$files\n"
> +printf "%s" "$files\n"
I think
printf "%s\n" "$files"
would be clearer.
>
> IFS='
> '
^ permalink raw reply
* Re: [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script
From: Matthieu Moy @ 2013-02-08 17:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20130208042800.GB4157@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> That seems much cleaner to me. If done right, it could also let people
> put:
>
> CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
Actually, you can already do this:
SCRIPT_PERL += contrib/mw-to-git/git-remote-mediawiki.perl
probably not by design, but it works!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] user-manual: Rewrite git-gc section for automatic packing
From: Junio C Hamano @ 2013-02-08 17:36 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <7ac63ea832711ad4bee636163e277a408cbddda4.1360341577.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> This should have happened back in 2007, when `git gc` learned about
> auto:
>
> commit e9831e83e063844b90cf9e525d0003715dd8b395
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Mon Sep 17 00:39:52 2007 -0700
>
> git-gc --auto: add documentation.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> I'd also be happy just dropping the whole git-gc section ;).
>
> Documentation/user-manual.txt | 16 ++++++----------
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 5077e7c..d14e3c7 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1562,17 +1562,13 @@ Ensuring good performance
> -------------------------
>
> On large repositories, Git depends on compression to keep the history
> -information from taking up too much space on disk or in memory.
> +information from taking up too much space on disk or in memory. Some
> +git commands may automatically run linkgit:git-gc[1], so you don't
> +have to worry about running it manually. However, compressing large
> +repositories may take some time, so you might want to disable
> +automatic comression and run it explicitly when you are not doing
> +other work.
I'd rather phrase it like "... may take long, so you would want to
run it explicitly from time to time to avoid automatic gc kicking in
when it is not convenient for you".
> -This compression is not performed automatically. Therefore you
> -should occasionally run linkgit:git-gc[1]:
> -
> --------------------------------------------------
> -$ git gc
> --------------------------------------------------
> -
> -to recompress the archive. This can be very time-consuming, so
> -you may prefer to run `git gc` when you are not doing other work.
Removal of this is a good change, though.
^ permalink raw reply
* Re: [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script
From: Jeff King @ 2013-02-08 17:43 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqzjzeaevm.fsf@grenoble-inp.fr>
On Fri, Feb 08, 2013 at 06:34:37PM +0100, Matthieu Moy wrote:
> Jeff King <peff@peff.net> writes:
>
> > That seems much cleaner to me. If done right, it could also let people
> > put:
> >
> > CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
>
> Actually, you can already do this:
>
> SCRIPT_PERL += contrib/mw-to-git/git-remote-mediawiki.perl
>
> probably not by design, but it works!
So putting:
ROOT=contrib/mw-to-git
git-remote-mediawiki: FORCE
@make -C ../.. SCRIPT_PERL=$(ROOT)/$@.perl $(ROOT)/$@
in contrib/mw-to-git/Makefile would already work? Neat.
-Peff
^ permalink raw reply
* Re: [PATCH] graph: output padding for merge subsequent parents
From: Matthieu Moy @ 2013-02-08 17:52 UTC (permalink / raw)
To: John Keeping; +Cc: Dale R. Worley, gitster, git
In-Reply-To: <20130206195702.GA1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> diff --git a/graph.c b/graph.c
> index 391a712..2a3fc5c 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -1227,6 +1227,16 @@ void graph_show_commit(struct git_graph *graph)
> if (!graph)
> return;
>
> + /*
> + * When showing a diff of a merge against each of its parents, we
> + * are called once for each parent without graph_update having been
> + * called. In this case, simply output a single padding line.
> + */
> + if (graph_is_commit_finished(graph)) {
> + graph_show_padding(graph);
> + shown_commit_line = 1;
> + }
> +
> while (!shown_commit_line && !graph_is_commit_finished(graph)) {
This works, but if we know we're not going to enter the while loop, it
seams even easier to do this:
--- a/graph.c
+++ b/graph.c
@@ -1227,7 +1227,17 @@ void graph_show_commit(struct git_graph *graph)
if (!graph)
return;
- while (!shown_commit_line && !graph_is_commit_finished(graph)) {
+ /*
+ * When showing a diff of a merge against each of its parents, we
+ * are called once for each parent without graph_update having been
+ * called. In this case, simply output a single padding line.
+ */
+ if (graph_is_commit_finished(graph)) {
+ graph_show_padding(graph);
+ return;
+ }
+
+ while (!shown_commit_line) {
shown_commit_line = graph_next_line(graph, &msgbuf);
fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
if (!shown_commit_line)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Ramkumar Ramachandra @ 2013-02-08 18:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git List
In-Reply-To: <7vwqui3fcc.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> We have the problem now that new users do not necessarily understand the
>> matching strategy, or why it is useful, and get confused. When we move
>> to "simple", we may be switching to a world where the early part of the
>> learning curve is more gentle for those users, but they eventually run
>> across the steeper part when they want to adjust their workflow (i.e.,
>> they will eventually learn about non-symmetric repo topologies because
>> those are part of many useful workflows).
>>
>> But I think it's a good thing to push that part of the learning curve
>> out, because:
>>
>> 1. Some people may stay in the centralized view their whole lives and
>> never care.
>>
>> 2. It will make more sense to them, because they'll understand how it
>> fits into what they're trying to do, rather than viewing it as an
>> arcane and senseless default.
>>
>> There may be some confusion as people hit that learning point. I won't
>> be surprised if we end up adding more advice.* messages in certain cases
>> to guide people to adjusting their push.default. But I'm just as happy
>> to wait until people start hitting the confusion point in practice, and
>> we can see more clearly when that advice should trigger, and what it
>> should say.
>
> Oh, I agree with you that adding new support for triangular workflow
> will not hurt the centralized folks. I was more interested about
> helping the "fetch from here, push to there" people.
In Git, there will always be a combination of switches which allows
you to go the centralized workflow mode. We're focusing on expanding
this list of switches, to free up distributed workflows into more
possibilities. We're currently targeting problems that affect us
everyday; the ones we've failed to notice.
> Centralized people do not have to configure anything for each branch
> for "git push" to push their current branch to where they fetch from
> and to the same name (you start building on their 'master', your
> result go to their 'master', because as a centralized person, you
> are part of 'them'). They have branch.$name.merge that names what
> their $name branch merges with, and that is sufficient to decide to
> which branch the result is to be pushed back.
What about the branch.$name.pushRef, which was proposed earlier? They
should be able to say, at a per-branch level, which branches to send
for review (in Gerrit).
> With the "push.defaultTo = peff" to name what remote the "git push"
> will push to, or even with the "branch.master.remotepush = peff" to
> decide that per branch, would "fetch from here, push to there"
> people have a way similar to what branch.$name.merge gives to the
> centralized people to decide what branch is updated?
Ah.
> It almost seems to me that we may want to extend the semantics given
> to the remote.$name.push refspecs. They are primarily for "perfect
> all branches you are going to push out, and push them in one go with
> 'git push'" workflow, but if it is clear that you are not following
> that (e.g. you are doing an equivalent of what the centralized folks
> would do with "push.default = simple/upstream/current") and pushing
> only the current branch, perhaps we should look at these refspecs to
> see where the current branch goes?
I'd actually just go with the current syntax + per-branch overrides.
Simple and serves the purpose: I don't think there'll be real usecases
outside this.
> In your case, 'refs/heads/master' would likely to go to
> 'refs/heads/master', and we could treat a missing remote.peff.push
> an equivalent to having remote.peff.push = refs/heads/*:refs/heads/*
I'll get to work on a patch that deems the configuration variable as
not "necessary".
^ permalink raw reply
* [PATCH] user-manual: Update for receive.denyCurrentBranch=refuse
From: W. Trevor King @ 2013-02-08 17:04 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
acd2a45 (Refuse updating the current branch in a non-bare repository
via push, 2009-02-11) changed the default to refuse such a push, but
it forgot to update the docs.
7d182f5 (Documentation: receive.denyCurrentBranch defaults to
'refuse', 2010-03-17) updated Documentation/config.txt, but forgot to
update the user manual.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5077e7c..8e55794 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1994,8 +1994,10 @@ handling this case.
Note that the target of a "push" is normally a
<<def_bare_repository,bare>> repository. You can also push to a
repository that has a checked-out working tree, but the working tree
-will not be updated by the push. This may lead to unexpected results if
-the branch you push to is the currently checked-out branch!
+will not be updated by the push. To protect against this, pushes to
+the currently checked-out branch of a repository are denied by
+default. See the description of the receive.denyCurrentBranch option
+in linkgit:git-config[1] for details.
As with `git fetch`, you may also set up configuration options to
save typing; so, for example, after
--
1.8.1.336.g94702dd
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox