Re: Problem: staging of an alternative repository
On Thu, May 1, 2014 at 4:35 AM, Jonathan Nieder jrnie...@gmail.com wrote: Now I know, the '--git-dir' option may usually be meant to use when the repository is somewhere outside of the work tree, and such a problem would not arise. And even if it is inside, sure enough, you can add this '.git_new' to the ignores or excludes. But is this really what you expect? I think it's more that it never came up. Excluding the current $GIT_DIR from what git add can add (on top of the current rule of excluding all instances of .git) seems like a sensible change, assuming it can be done without hurting the code too much. ;-) I think it came up before. Changes could be very messy (but I did not check carefully) because right now we just compare $(basename $path) with .git, one path component, simple and easy. Checking against $GIT_DIR means all path components. You also have to deal with relative and absolute paths and symlinks in some path components. You may also need to think if submodule detection code (checking .git again) is impacted. On top of that, read_directory() code is already messy (or at least scary to me) with all kinds of shortcuts we have added over the years. A simpler solution may be ignoring all directories whose last component is $GIT_DIR_NAME (e.g. GIT_DIR_NAME=.git_new). -- Duy -- 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
Re: Pull is Evil
On Thu, 01 May 2014 16:21:42 +, Marc Branchaud wrote: ... But these days there's hardly any risk to using a detached HEAD. Plus nowadays I think it's commonly accepted that using topic branches is a git best practice. The notion of doing work on a generically-named branch like maint seems archaic. So what benefit does git pull provide? It provides the moral equivalent of 'cvs update', 'svn update', and 'clearcase do nothing'. Even when I'm on a feature branch, there are cases where I have that branch as the current one in multiple repos (on different machines because testing), or multiple people working on that branch. A 'git pull' is the obvious way to get divergent branches back together. In cvssvn a local workspace can't ever be more than half a commit ahead, and what an 'update' does is most similar to a rebase in git. But I'm not eager to teach this future userbase rebases, and also a rebase loses expensive test results that are tied to the commit ids. My personal beef with 'git pull' is still that sometimes (namely in the 'git pull git push' sequence) it should reverse the order of the parents in the merge commit, so that *my* commits look like an integrated topic branch, instead of the former mainline. Unfortunately the answers to the question what to do instead of 'git pull' are, in increasing order of teaching needed: - Ok, just 'git pull' sigh. - Please do a 'git pull --rebase'; I'll show you how. - Something involving switching branches and doing the merge in the other direction (I'm coming from a 'blessed repo where everybody pushes to' setup, and we're considering a server trigger that refuses pushes where the previous head is not a *first* parent of the new head, in order not to accidentally mess up the mainline.) Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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
Re: Pull is Evil
On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote: ... I didn't mean replace 'pull' with 'update' everywhere. I meant Introduce 'update' that lets integrate your history into that from the remote, which is to integrate in a direction opposite from how 'pull' does. That still doesn't quite solve my problem. If I'm tracking origin/master in a local master branch, I can just use 'git pull' to get my 'feature' branch (which is named master) updated to the current state of the origin. This amounts to 'integrating' origin/master into my master. When I finally want to deliver and push to origin/master, I put on the integrator's hat, and I cat do a 'git update' that will do the merge in reverse, and push the result to origin/master. The result will look like origin pulled my master branch into his. Problem is that whether to use pull or update depends on whether I intend to push afterwards; and additionally, if I can push fast-forward without needing to 'git update' the integration into origin/master will look weird. (Oh, and please don't name it 'update' - we have an important alias of that name.) Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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
Re: [PATCH] Add extra logic required to detect endianness on Solaris
On Thu, May 01, 2014 at 11:58:26AM -0700, Junio C Hamano wrote: This patch seems to address two unrelated issues in that. (1) The existing support does not help a platform where the convention is to define either _BIG_ENDIAN (with one leading underscore) or _LITTLE_ENDIAN and not both, which is Solaris but there may be others. (2) There may be __LITTLE_ENDIAN and __BIG_ENDIAN macros already defined on the platform. Or these may not have been defined at all. You avoid unconditionally redefing these. I find the latter iffy. Yes, you are right. I think I was uncomfortable defining macros with names reserved for the implementation even if the implementation didn't seem to be using them. I think I made my patch less correct as a result. Looking at the rest of the git source code we don't seem to use any of these macros anywhere else so perhaps we could use macros specific to GIT? Let me follow up with an alternative patch. Charles. -- 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
[PATCH] Detect endianness on more platforms that don't use BYTE_ORDER
--- compat/bswap.h | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/compat/bswap.h b/compat/bswap.h index 120c6c1..f08a9fe 100644 --- a/compat/bswap.h +++ b/compat/bswap.h @@ -101,19 +101,34 @@ static inline uint64_t git_bswap64(uint64_t x) #undef ntohll #undef htonll -#if !defined(__BYTE_ORDER) -# if defined(BYTE_ORDER) defined(LITTLE_ENDIAN) defined(BIG_ENDIAN) -# define __BYTE_ORDER BYTE_ORDER -# define __LITTLE_ENDIAN LITTLE_ENDIAN -# define __BIG_ENDIAN BIG_ENDIAN +#if defined(BYTE_ORDER) defined(LITTLE_ENDIAN) defined(BIG_ENDIAN) + +# define GIT_BYTE_ORDER BYTE_ORDER +# define GIT_LITTLE_ENDIAN LITTLE_ENDIAN +# define GIT_BIG_ENDIAN BIG_ENDIAN + +#elif defined(__BYTE_ORDER) defined(__LITTLE_ENDIAN) defined(__BIG_ENDIAN) + +# define GIT_BYTE_ORDER __BYTE_ORDER +# define GIT_LITTLE_ENDIAN __LITTLE_ENDIAN +# define GIT_BIG_ENDIAN __BIG_ENDIAN + +#else + +# define GIT_BIG_ENDIAN 4321 +# define GIT_LITTLE_ENDIAN 1234 + +# if defined(_BIG_ENDIAN) !defined(_LITTLE_ENDIAN) +# define GIT_BYTE_ORDER GIT_BIG_ENDIAN +# elif defined(_BIG_ENDIAN) !defined(_LITTLE_ENDIAN) +# define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN +# else +# error Cannot determine endianness # endif -#endif -#if !defined(__BYTE_ORDER) -# error Cannot determine endianness #endif -#if __BYTE_ORDER == __BIG_ENDIAN +#if GIT_BYTE_ORDER == GIT_BIG_ENDIAN # define ntohll(n) (n) # define htonll(n) (n) #else -- 1.9.0 -- 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
Re: Pull is Evil
Andreas Krey wrote: My personal beef with 'git pull' is still that sometimes (namely in the 'git pull git push' sequence) it should reverse the order of the parents in the merge commit, so that *my* commits look like an integrated topic branch, instead of the former mainline. I haven't really thought much about this but it does make sense. How about changing the behavior so `git pull` by default changes the order of the parents, but `git pull repo branch` doesn't. -- 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
Re: Pull is Evil
Andreas Krey a.k...@gmx.de writes: On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote: ... I didn't mean replace 'pull' with 'update' everywhere. I meant Introduce 'update' that lets integrate your history into that from the remote, which is to integrate in a direction opposite from how 'pull' does. That still doesn't quite solve my problem. If I'm tracking origin/master in a local master branch, I can just use 'git pull' to get my 'feature' branch (which is named master) updated to the current state of the origin. This amounts to 'integrating' origin/master into my master. This discussion makes as much sense to me as debating whether git fiddle should, in case a simple git hammer does not apply, should translate to an implied git screwdriver, and when it does, whether more people's workflows involve turning a screw left rather than right by default. What the gibbins? I don't even use git pull. I use git fetch, and then, depending on my needs, I rebase or merge. git pull is not part of my workflow exactly because it does non-connected things not translating unambiguously to a particular identifiable workflow. It might sometimes, more by accident than design, do what I would have done anyway. But I prefer making that choice on my own, depending on the particular circumstances. -- David Kastrup -- 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
#178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
Hi, I’m very new to ‘git’ github. I reported the #178 issue in github and the issue has been closed, I believe this means no further discussion. There are a three additional comments, thank you to the contributors. The advise was to discuss upstream which meant nothing to me (again thanks to another contributor for clarification). Summary The issue reported is (in my opinion) a defect in argument processing (happens on Windows and Linux (as per another contributor)). The issue (in my opinion) is a defect for argument processing by Git. The decision (agreement or otherwise) I guess is for this upstream discussion. I appreciate the open-source git and its usage to the community. But this is owned by the discussion group and I doubt my involvement is wanted. So this will be my last communication on this issue. Context -- Over many years, I’ve used command-line on Unix/Linux/Windows in both hobby and professional modes. In the latter case the processing of arguments with spaces has often been the cause of defects (none expected behaviour) for newly introduced products. I’ve found no documentation about the pretty=format behaviour as described by the #178 issue. Also, there are many (but incomplete) google-it second-hand documents(?) about. So a document fix in the internet age is not necessarily the approach to solve an issue, as all those google-it items create fog. For this issue I was processing a git command to run in a GUI and happened upon it. The GUI (original design by me) allows interfacing with CVS, SVN, HG and maybe now GIT in a similar manner. The GUI holds the interfacing and access information and concatenates it onto the VCS command/sub-commands as appropriate for a request. Thus, the concatenated VCS request may be processed for copy-paste onto a command line window/terminal or (for my GUI) executed via a programming language’s command-line-execution class/function (Perl, Java, C,.). With the argument being further processed within git, it behaves in a manner that wasn’t expected. Thx Dave the Issue as reported Getting a fatal failure when using the following --pretty=format:%an %ad via a programmed execution from within a programming language. (Java using the execution capabilities puts the ' --pretty=format:%an %ad ' as an argument). This is reproduced on a Windows command-line entry by putting double-quotes around the argument. (see below for various examples of pass, fail and testing around). The git argument parser appears to perform a split on spaces within the arguments passed to it also. This is not a normal behaviour for any parsing. Also, the split is happening within a string quote, it would appear (%an %ad). Even tried %20 to represent the space. Thx G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + -- 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
Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
On Fri, May 2, 2014 at 1:50 PM, Dave Bradley dbradl...@bell.net wrote: Hi, I’m very new to ‘git’ github. I reported the #178 issue in github and the issue has been closed, I believe this means no further discussion. When you say the #178 issue in github, you really mean issue #178 for Git for Windows on GitHub, available at https://github.com/msysgit/git/issues/178 for those interested. That issue tracker is for the Windows port of Git for Windows. It's intended to track breakages in Git for Windows compared to Git on, say Linux. It's not a general issue tracker for problems with Git. Still, it seems a lot of people think I downloaded Git for Windows, and here's something that didn't work the way I expected it to, I'll file a bug. Those kinds of bug-reports usually gets closed quickly, as it's outside the scope of Git for Windows to decide how Git should behave - we try to make it behave consistently between Windows and Unixy-platforms. This is indeed the right forum to address your issue. So thank you for moving the discussion here. -- 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
Re: [PATCH v6 1/7] pull: rename pull.rebase to pull.mode
On Thu, May 01, 2014 at 07:00:02PM -0500, Felipe Contreras wrote: Also 'branch.name.rebase' to 'branch.name.pullmode'. Perhaps this has already been hashed out in a previous version of this series, but we may want to use pull.update and branch.name.update to match the existing submodule.name.update. Both settings are selecting the default integration style between HEAD and some other reference (pull's remote branch, the gitlinked commit, or the submodule's --remote branch). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v6 20/42] fetch.c: clear errno before calling functions that might set it
Fixed. Thanks. On Thu, May 1, 2014 at 9:11 PM, Eric Sunshine sunsh...@sunshineco.com wrote: On Thu, May 1, 2014 at 4:37 PM, Ronnie Sahlberg sahlb...@google.com wrote: In s_update_ref there are two calls that when they fail we return an error based on the errno value. In particular we want to return a specific error if ENOTDIR happened. Both these functions do have failure modes where they may return an error without updating errno, in which case a previous and unrelated ENOTDIT may cause us to return the wrong error. Clear errno before s/ENOTDIT/ENOTDIR/ calling any functions if we check errno afterwards. Also skip initializing a static variable to 0. Statics live in .bss and are all automatically initialized to 0. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- builtin/fetch.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/builtin/fetch.c b/builtin/fetch.c index 55f457c..a93c893 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -44,7 +44,7 @@ static struct transport *gtransport; static struct transport *gsecondary; static const char *submodule_prefix = ; static const char *recurse_submodules_default; -static int shown_url = 0; +static int shown_url; static int option_parse_recurse_submodules(const struct option *opt, const char *arg, int unset) @@ -382,6 +382,8 @@ static int s_update_ref(const char *action, if (!rla) rla = default_rla.buf; snprintf(msg, sizeof(msg), %s: %s, rla, action); + + errno = 0; lock = lock_any_ref_for_update(ref-name, check_old ? ref-old_sha1 : NULL, 0, NULL); -- 2.0.0.rc1.351.g4d2c8e4 -- 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
Re: [PATCH v6 40/42] refs.c: pass a skip list to name_conflict_fn
Fixed. Thanks.
On Thu, May 1, 2014 at 9:22 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Thu, May 1, 2014 at 4:37 PM, Ronnie Sahlberg sahlb...@google.com wrote:
Allow passing a list of refs to ckip checking to name_conflict_fn.
s/ckip/skip/
There are some conditions where we want to allow a temporary conflict and
skip
checking those refs. For example if we have a transaction that
1, guarantees that m is a packed refs and there is no loose ref for m
2, the transaction will delete m from the packed ref
3, the transaction will create conflicting m/m
For this case we want to be able to lock anc create m/m since we know that
the
s/anc/and/
conflict is only transient. I.e. the conflict will be automatically resolved
by the transaction when it deletes m.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 43 +--
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/refs.c b/refs.c
index b525076..eb75927 100644
--- a/refs.c
+++ b/refs.c
@@ -789,11 +789,19 @@ struct name_conflict_cb {
const char *refname;
const char *oldrefname;
const char *conflicting_refname;
+ const char **skip;
+ int skipnum;
};
static int name_conflict_fn(struct ref_entry *entry, void *cb_data)
{
struct name_conflict_cb *data = (struct name_conflict_cb *)cb_data;
+ int i;
+ for(i = 0; i data-skipnum; i++) {
+ if (!strcmp(entry-name, data-skip[i])) {
+ return 0;
+ }
+ }
if (data-oldrefname !strcmp(data-oldrefname, entry-name))
return 0;
if (names_conflict(data-refname, entry-name)) {
@@ -808,15 +816,21 @@ static int name_conflict_fn(struct ref_entry *entry,
void *cb_data)
* conflicting with the name of an existing reference in dir. If
* oldrefname is non-NULL, ignore potential conflicts with oldrefname
* (e.g., because oldrefname is scheduled for deletion in the same
- * operation).
+ * operation). skip contains a list of refs we want to skip checking for
+ * conflicts with. Refs may be skipped due to us knowing that it will
+ * be deleted later during a transaction that deletes one reference and then
+ * creates a new conflicting reference. For example a rename from m to m/m.
*/
static int is_refname_available(const char *refname, const char *oldrefname,
- struct ref_dir *dir)
+ struct ref_dir *dir,
+ const char **skip, int skipnum)
{
struct name_conflict_cb data;
data.refname = refname;
data.oldrefname = oldrefname;
data.conflicting_refname = NULL;
+ data.skip = skip;
+ data.skipnum = skipnum;
sort_ref_dir(dir);
if (do_for_each_entry_in_dir(dir, 0, name_conflict_fn, data)) {
@@ -2032,7 +2046,8 @@ int dwim_log(const char *str, int len, unsigned char
*sha1, char **log)
static struct ref_lock *lock_ref_sha1_basic(const char *refname,
const unsigned char *old_sha1,
- int flags, int *type_p)
+ int flags, int *type_p,
+ const char **skip, int skipnum)
{
char *ref_file;
const char *orig_refname = refname;
@@ -2079,7 +2094,9 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
* name is a proper prefix of our refname.
*/
if (missing
-!is_refname_available(refname, NULL,
get_packed_refs(ref_cache))) {
+!is_refname_available(refname, NULL,
+ get_packed_refs(ref_cache),
+ skip, skipnum)) {
last_errno = ENOTDIR;
goto error_return;
}
@@ -2137,7 +2154,7 @@ struct ref_lock *lock_any_ref_for_update(const char
*refname,
const unsigned char *old_sha1,
int flags, int *type_p)
{
- return lock_ref_sha1_basic(refname, old_sha1, flags, type_p);
+ return lock_ref_sha1_basic(refname, old_sha1, flags, type_p, NULL,
0);
}
/*
@@ -2576,6 +2593,9 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
int log = !lstat(git_path(logs/%s, oldrefname), loginfo);
const char *symref = NULL;
+ if (!strcmp(oldrefname, newrefname))
+ return 0;
+
if (log S_ISLNK(loginfo.st_mode))
return error(reflog for %s is a symlink, oldrefname);
@@ -2586,10 +2606,12 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
if (!symref)
return error(refname %s not found, oldrefname);
- if
Re: Pull is Evil
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v6 5/7] pull: add merge-ff-only option
On Thu, May 01, 2014 at 07:00:06PM -0500, Felipe Contreras wrote: It is very typical for Git newcomers to inadvertently create merges and worst; inadvertently pushing them. This is one of the reasons many experienced users prefer to avoid 'git pull', and recommend newcomers to avoid it as well. To avoid these problems and keep 'git pull' useful, it has been suggested that 'git pull' barfs by default if the merge is non-fast-forward, which unfortunately would break backwards compatibility. This patch leaves everything in place to enable this new mode, but it only gets enabled if the user specifically configures it; pull.mode = merge-ff-only. The subject and commit message also need “merge-ff-only” → “ff-only”. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Pull is Mostly Evil
(Apologies for not CCing all the folks who've participated in the Pull is Evil thread -- I couldn't find a good branch of that thread for this message.) OK, so maybe git pull is just Mostly Evil. People seem to have found many different ways to make it work for them. But in reality git pull has become a chimera that confuses a large number of new users, and that experienced users either avoid entirely or customize to give them a convenient shorthand for working in their particular environment. As a tool for new git users, it just doesn't seem to be achieving its goals. I think the git project as a whole would benefit if it started to treat git pull as an advanced command, in the sense that it needs to be configured by an experienced user in order to make it correctly follow a project's workflow. Once it's configured properly, git pull is a powerful tool that gives users an easy way to do complex things. In that sense, it may be appropriate for a project to tailor git pull as it likes, then teach its own users to use the command. However, when it comes to teaching people how to use git qua git, git pull should be the last thing they learn about, because it's only after you understand various basic git concepts that you can configure git pull to do the right thing. To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. It'll take quite a bit of time, but I think that if we change our attitude towards git pull and take this unconfigured-by-default approach, then in a few years the entire git ecosystem will be in a better place. M. -- 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
Re: Pull is Mostly Evil
Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. It's just when the merge-left/merge-right/rebase-left/rebase-right decision kicks in that prescribing one git-pull behavior looks like a recipe for trouble. -- David Kastrup -- 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
Re: Pull is Mostly Evil
From: David Kastrup d...@gnu.org Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. While the fast forward is /pretty/ uncontentious, it still maybe contentious for some. But more importantly (in my mind) is the fact that it (git pull) hasn't been configured, and pressing for _that_ to happen is the big benefit. I'm more than happy that the fast-forward should be the recommended 'if you don't know, choose this' option, as you say, its pretty uncontentious and has easy mechanisms for backing out which are well illustrated across the internet. It would still need a few cycles of ramping up the warnings to ease folk in gently. One has to beware of the issues at both ends of the Kruger Dunning curve. This thread discussion in some ways has suffered from the inverse K-D effect. It's just when the merge-left/merge-right/rebase-left/rebase-right decision kicks in that prescribing one git-pull behavior looks like a recipe for trouble. -- David Kastrup -- Philip -- 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
Re: Zsh submodule name completion borked
On Thu, May 1, 2014 at 6:35 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Phil Hord wrote: When I use zsh tab-completion to complete the submodule name in 'git submodule init', I get more than I expected. From the gerrit repository (which has plugins): $ git submodule init plugins/TAB plugins/commit-message-length-validator\ \(v1.0-rc1-9-g545000b\) plugins/reviewnotes\ \(v1.0-rc1-8-ge984300\) plugins/replication\ \(v1.1-rc0-13-g4c3f4c9\) It works ok in bash. I tried to bisect the trouble, but it still fails in 1.8.3, so I'm beginning to think it's me. Does this happen to anyone else? Is it something in my local configuration causing this? It seems to be something local. I thought the issue persisted with no local .zshrc config, but it looks like I only turned off my local config and not the global settings. The recent Ubuntu update is a likely culprit. I'll investigate locally and turn my reports up to Ubuntu/Debian/Zshell. Define 'works' in bash. From what I can see from the bash completion, it's not doing anything special, so the completion you see are simply files. To clarify my description in case anyone else sees it or is interested, before I load /etc/zsh/zshrc, tab gives me simple filename expansion. After I load /etc/zsh/zshrc, tab expands only submodules in HEAD. But for some reason it gets the wrong kind of results in the expansion, returning not just submodule paths, but submodule paths with tag info appended. Sample session: $ zsh --norcs % git submodule init plugins/TAB commit-message-length-validator/ README reviewnotes/ replication/ ^C % source /etc/zsh/zshrc % git submodule init plugins/TAB plugins/commit-message-length-validator\ \(v1.0-rc1-9-g545000b\) plugins/reviewnotes\ \(v1.0-rc1-8-ge984300\) plugins/replication\ \(v1.1-rc0-13-g4c3f4c9\) -- 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
Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER
Charles Bailey cbaile...@bloomberg.net writes: --- Please sign-off your patches ;-) This swaps the precedence of BYTE_ORDER and __BYTE_ORDER from the original, which we may not want to. It is easy for me to swap the order of if/elif to restore it, so it is not a big deal, though. Thanks. compat/bswap.h | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/compat/bswap.h b/compat/bswap.h index 120c6c1..f08a9fe 100644 --- a/compat/bswap.h +++ b/compat/bswap.h @@ -101,19 +101,34 @@ static inline uint64_t git_bswap64(uint64_t x) #undef ntohll #undef htonll -#if !defined(__BYTE_ORDER) -# if defined(BYTE_ORDER) defined(LITTLE_ENDIAN) defined(BIG_ENDIAN) -# define __BYTE_ORDER BYTE_ORDER -# define __LITTLE_ENDIAN LITTLE_ENDIAN -# define __BIG_ENDIAN BIG_ENDIAN +#if defined(BYTE_ORDER) defined(LITTLE_ENDIAN) defined(BIG_ENDIAN) + +# define GIT_BYTE_ORDER BYTE_ORDER +# define GIT_LITTLE_ENDIAN LITTLE_ENDIAN +# define GIT_BIG_ENDIAN BIG_ENDIAN + +#elif defined(__BYTE_ORDER) defined(__LITTLE_ENDIAN) defined(__BIG_ENDIAN) + +# define GIT_BYTE_ORDER __BYTE_ORDER +# define GIT_LITTLE_ENDIAN __LITTLE_ENDIAN +# define GIT_BIG_ENDIAN __BIG_ENDIAN + +#else + +# define GIT_BIG_ENDIAN 4321 +# define GIT_LITTLE_ENDIAN 1234 + +# if defined(_BIG_ENDIAN) !defined(_LITTLE_ENDIAN) +# define GIT_BYTE_ORDER GIT_BIG_ENDIAN +# elif defined(_BIG_ENDIAN) !defined(_LITTLE_ENDIAN) +# define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN +# else +# error Cannot determine endianness # endif -#endif -#if !defined(__BYTE_ORDER) -# error Cannot determine endianness #endif -#if __BYTE_ORDER == __BIG_ENDIAN +#if GIT_BYTE_ORDER == GIT_BIG_ENDIAN # define ntohll(n) (n) # define htonll(n) (n) #else -- 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
Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER
On Fri, May 02, 2014 at 09:48:58AM -0700, Junio C Hamano wrote: Charles Bailey cbaile...@bloomberg.net writes: --- Please sign-off your patches ;-) Oops! Please consider this patch... Signed-off-by: Charles Bailey cbaile...@bloomberg.net This swaps the precedence of BYTE_ORDER and __BYTE_ORDER from the original, which we may not want to. It is easy for me to swap the order of if/elif to restore it, so it is not a big deal, though. I think I swapped the precedence (semi-deliberately) because I found a proposal to standardize the BYTE_ORDER variant. I claim that any platform which provides both but with differing senses is somewhat broken so I cannot see the precedence mattering much. I don't mind either way. Charles. -- 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
Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, May 2, 2014 at 1:50 PM, Dave Bradley dbradl...@bell.net wrote:
Hi,
I’m very new to ‘git’ github. I reported the #178 issue in github and the
issue has been closed, I believe this means no further discussion.
When you say the #178 issue in github, you really mean issue #178
for Git for Windows on GitHub, available at
https://github.com/msysgit/git/issues/178 for those interested.
That issue tracker is for the Windows port of Git for Windows. It's
intended to track breakages in Git for Windows compared to Git on, say
Linux. It's not a general issue tracker for problems with Git. Still,
it seems a lot of people think I downloaded Git for Windows, and
here's something that didn't work the way I expected it to, I'll file
a bug. Those kinds of bug-reports usually gets closed quickly, as
it's outside the scope of Git for Windows to decide how Git should
behave - we try to make it behave consistently between Windows and
Unixy-platforms.
This is indeed the right forum to address your issue. So thank you for
moving the discussion here.
Hmm, everything you said in the earlier paragraphs is correct,
but I am having a feeling that this is either an issue specific to
the Windows port, or more likely a user error, depending on who is
giving the extra dq quoting. From the command line:
$ git show --pretty='format:%an %ad'
Junio C Hamano Wed Apr 30 11:01:42 2014 -0700
Because the 'format:' specifier requests to put dq around these two,
we respond by putting dq around these two, just as we were asked to
do. The way to ask %an followed by SP followed by %ad and nothing
else is
$ git show --pretty='format:%an %ad'
Junio C Hamano Wed Apr 30 11:01:42 2014 -0700
Especially this part from the original tells me that this is a user
error and there is nothing wrong in either the generic Git or in the
Windows port.
G:\wxgit log --all --pretty=format:%an %ad -- pom.xml
fatal: bad revision '%ad'
Separating the tokens on that command line, we would get:
git
log
--all
--pretty=format:%an
%ad
--
pom.xml
So it told git to run the log subcommand with arguments that tells
it to include all tips of refs to the starting set, show them
using a custom format %an, include %ad to the starting set,
everything that follows are not revs but pathspecs, and then
finally pom.xml is the pathspec to limit to paths the user is
interested in. %ad is not a rev is perfectly valid.
You cannot take --pretty=format:%ad %an that you see in tutorials
and random web pages too literally. The double quotes you see in
that example is our way to tell that --pretty=format:%ad %an (what
is inside these dq) is expected to be fed to Git as a single
argument.
The examples you see typically follow the convention to show what
you _would_ give to shell to achieve that, and shell's command line
parser needs these dq to make sure that the SP between %an and %ad
is not taken as an argument separator.
Your custom front-end may take a different approach to let you
specify what individual arguments are on your command line, and you
would have to follow its convention. The user needs to be careful
about how shell quoting works on his/her command line, and that is
all, I would think.
Visiting an earlier part of the original issue report:
Getting a fatal failure when using the following
--pretty=format:%an %ad via a programmed execution from within
a programming language. (Java using the execution capabilities
puts the ' --pretty=format:%an %ad ' as an argument).
I take that Java using ... to mean that the user wants to see his
machinery eventually do an equivalent to:
execl('git', 'git', 'log', '--pretty=format:%an %ad', ...);
but it somehow is getting
execl('git', 'git', 'log', '--pretty=format:%an', '%ad', ...);
due to reason unknown to us that is not in the report.
Without knowing what the end-user input to the front-end that calls
into that Java machinery is and what the argument separating
convention that is employed by the front-end is, I cannot tell where
the single argument is split into two. The problem may either be in
that front-end program and not in the end-user input. Or the
problem may be in Windows port letting the Windows library split
command line at a funny point. In any case, it does not sound like
it is a problem in Git. If the command fed to the equivalent to
execl() above were not 'git' but any program, it will suffer from
the same issue.
--
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
Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
Hi Dave, Dave Bradley wrote: G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' On Linux, this example gets passed to git as six arguments: log --all --pretty=format:%an %ad -- pom.xml I think the intent was instead to pass five arguments (the third being '--pretty=format:%an %ad'). That means you shouldn't unquote before the space, or in other words that the space should be part of a quoted argument. On Windows, I believe the argument passing convention is more complicated. Programs can inspect the entire command line if they want to. But there's still an ambiguity in the command you passed: if I look at space-separated or double-quoted parts of the command line, it looks like git log --all --pretty=format: (no space) %an %ad (no space) -- pom.xml What's the right way to parse this? How can git tell whether %an %ad were meant to be separate arguments or not? In absence of a stronger convention I suspect the simplest rule is to mimic what a Unix shell does, where they are separate arguments because the space is not quoted. Cc-ing Windows folks in case they have more insight. Thanks and hope that helps, Jonathan -- 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
Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
(resending with the correct address for the Git for Windows developers. Sorry for the noise.) Hi Dave, Dave Bradley wrote: G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' On Linux, this example gets passed to git as six arguments: log --all --pretty=format:%an %ad -- pom.xml I think the intent was instead to pass five arguments (the third being '--pretty=format:%an %ad'). That means you shouldn't unquote before the space, or in other words that the space should be part of a quoted argument. On Windows, I believe the argument passing convention is more complicated. Programs can inspect the entire command line if they want to. But there's still an ambiguity in the command you passed: if I look at space-separated or double-quoted parts of the command line, it looks like git log --all --pretty=format: (no space) %an %ad (no space) -- pom.xml What's the right way to parse this? How can git tell whether %an %ad were meant to be separate arguments or not? In absence of a stronger convention I suspect the simplest rule is to mimic what a Unix shell does, where they are separate arguments because the space is not quoted. Cc-ing Windows folks in case they have more insight. Thanks and hope that helps, Jonathan -- 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
Re: Pull is Mostly Evil
Marc Branchaud marcn...@xiplink.com writes: (Apologies for not CCing all the folks who've participated in the Pull is Evil thread -- I couldn't find a good branch of that thread for this message.) OK, so maybe git pull is just Mostly Evil. People seem to have found many different ways to make it work for them. But in reality git pull has become a chimera that confuses a large number of new users, and that experienced users either avoid entirely or customize to give them a convenient shorthand for working in their particular environment. As a tool for new git users, it just doesn't seem to be achieving its goals. I think the git project as a whole would benefit if it started to treat git pull as an advanced command, in the sense that it needs to be configured by an experienced user in order to make it correctly follow a project's workflow. Once it's configured properly, git pull is a powerful tool that gives users an easy way to do complex things. In that sense, it may be appropriate for a project to tailor git pull as it likes, then teach its own users to use the command. However, when it comes to teaching people how to use git qua git, git pull should be the last thing they learn about, because it's only after you understand various basic git concepts that you can configure git pull to do the right thing. To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. It'll take quite a bit of time, but I think that if we change our attitude towards git pull and take this unconfigured-by-default approach, then in a few years the entire git ecosystem will be in a better place. Your earlier long-hand, together with the two examples that pulls into the same maint branch Brian gave us, may give us a better starting points to think about a saner way. To me, the problem sounds like: Tutorials of Git often says use 'git pull' to catch up your branch with your upstream work and then 'git push' back (and worse yet, 'git push' that does not fast-forward suggests doing so), but 'git pull' that creates a merge in a wrong direction is not the right thing for many people. And proposed solutions range from let's write 'pull' off as a failed experiment to let's forbid any merge made by use of 'pull' by default, because it is likely that merge may be in reverse. Let's look at Brian's examples, which may point at a good direction. When he becomes in charge of producing a new 'maint' (in his original, he says 'maintenance-branch'), he first does this: $ git checkout maint $ git pull --ff-only [ origin maint ] He may have a stale 'maint' branch for a variety of reasons. He may have been the pumpking in the past, worked on his local 'maint' to advance its tip with merges in the right direction and pushed the result out to the central repository when he was done, and kept that then-current 'maint' in his repository without removing when he passed the pumpkin to somebody else. As you said in the thread, this could have been done on a detached head, but keeping the local branch around is more convenient (you may want to do a disconnected development and having a reference point is handy). Or he may be the long-term pumpking for 'maint' branch, but is working on a machine different from the one he updated the shared 'maint' the last time. In either case, what is most important for this 'pull' is that he is catching up with today's central repository, without losing any old work that he forgot to push out when he was playing the pumpking the last time (hence --ff-only to cause it to fail if that is the case) in this local repository. Then he integrates a topic by another and push the result with: $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] For this 'pull', he knows that this may not fast-forward (the $DAYJOB convention to use a real merge even when the merge fast-forwards is optional). Even with the proposed pull.mode or branch.maint.pullmode, these two 'pull' cannot be given a convenient default. The best we can do with the approach is to set pull.mode to ff-only for safety to protect his first 'pull' from the origin/maint, and have him remember to override it from the command line with --merge --no-ff [*1*]. If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push
Re: [PATCH 7/8] CodingGuidelines: on comparison
Jeff King p...@peff.net writes: On Wed, Apr 30, 2014 at 02:45:11PM -0700, Junio C Hamano wrote: See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126 Signed-off-by: Junio C Hamano gits...@pobox.com Don't you often complain about submitters referencing a discussion in a commit message without providing some context or summary? Yes, but the summary of the discussion would be identical to the new text added by the patch to the documentation tree in this case, so I didn't find a good introductory text before See $URL. Perhaps This comes up from time to time. See $URL for the original discussion. but I do not know if that is much better. + - There are two schools of thought when it comes to comparison, + especially inside a loop. Some people prefer to have less stable + value on the left hand side and more stable value on the right hand + side, e.g. if you have a loop that counts variable i down to the + lower bound, Grammar: /(less|more) stable/the / + Both are valid, and we use both, even though we tend to see the + former the more preferable, the more stable the more stable side + becomes (comparison with a constant, i 0, is an extreme + example). Just do not mix styles in the same part of the code. + I had trouble parsing the first sentence. Maybe: Both are valid, and we use both. However, the more stable the stable side becomes, the more we tend to prefer the former (comparison with a constant[...] Thanks. That is much better. -- 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
Re: [msysGit] Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
On Fri, May 2, 2014 at 7:23 PM, Jonathan Nieder jrnie...@gmail.com wrote: (resending with the correct address for the Git for Windows developers. Sorry for the noise.) Hi Dave, Dave Bradley wrote: G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' On Linux, this example gets passed to git as six arguments: log --all --pretty=format:%an %ad -- pom.xml As does it on Windows. -- 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
Re: [PATCH 1/8] CodingGuidelines: typofix
Jeff King p...@peff.net writes: On Thu, May 01, 2014 at 10:51:19AM -0700, Junio C Hamano wrote: If you want to fix something here, do s/judgement/judgment/ instead. That too. FWIW, neither is outright wrong; it is an America/British variation, and apparently dictionaries disagree on which is preferred. My reading of various grammar sites was that even though variation exists[*1*], the form without 'e' is the traditionally preferred form, and that is why I said That too. But let's follow this one: http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20callcmpt=q which seems to say that with 'e' is more common. [Footnote] *1* To Americans, the form with 'e' is abomination. Wikipedia claims that (1) without 'e' is in legal and (2) with 'e' in other contexts in British (this particular one is a non-legal use), and (3) both are equally acceptable in non-legal contexts in Austraria and Canada. -- 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
Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. It wouldn't matter if by the default non-fast-forward merges are rejected. -- 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
Re: Pull is Evil
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. It wouldn't matter if by the default non-fast-forward merges are rejected. It would matter if you didn't want them making non-fast-forward merges (e.g. for explicitly-merged topic branches). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Pull is Evil
W. Trevor King wk...@tremily.us writes: On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. It wouldn't matter if by the default non-fast-forward merges are rejected. It would matter if you didn't want them making non-fast-forward merges (e.g. for explicitly-merged topic branches). s/didn't want/only wanted/ -- David Kastrup -- 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
Re: Pull is Mostly Evil
Philip Oakley wrote: From: David Kastrup d...@gnu.org Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. While the fast forward is /pretty/ uncontentious, it still maybe contentious for some. So? No defaults can please absolutely everyone, the best anybody can do is try to please the majority of people, and merging fast-forwards only does 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
Re: Pull is Mostly Evil
Junio C Hamano wrote: If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push does not fast-forward. In addition to barf when it's not a fast-forward, such command can switch the parents, so it appears 'maint' was merged to 'origin/maint'. Many people have complained about this order. Stepping back even further, and thinking what is different between these two pulls, we notice that the first one is pulling from the place we push back to. Perhaps a way to solve this issue, without having to introduce a new 'git update' and updating the tutorials, may be disallow fetch+merge by default only when pulling from the place the result is going to be pushed back to? Which is basically essentially the same as not specifying anything, or rather, running `git pull` without arguments. -- 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
Re: Pull is Evil
W. Trevor King wrote: On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. It wouldn't matter if by the default non-fast-forward merges are rejected. It would matter if you didn't want them making non-fast-forward merges (e.g. for explicitly-merged topic branches). It would matter almost exactly zero. And just as they can do pull.promot = true, they can do pull.mode = fetch-only. -- 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
Re: Pull is Evil
Marc Branchaud marcn...@xiplink.com writes: I may be mistaken, but I think git pull evolved to try to address the detached-HEAD risk (at least in part). You are totally mistaken. git pull was part of the things to make git usable by Linus before 1.0 release, and matches the integrator workflow perfectly well. The detached HEAD came much much later. The issue we are discussing with git pull is that if a non integrator does a git pull from the upstream, in order to push the result of integrating the local work with it back to the upstream, by default git pull creates a merge in a direction that is wrong when seen in the first-parent chain is the trunk point of view. One way to solve that _might_ be to use the detached HEAD as you illustrated in your long-hand in the thread that had Brian's example, but that is not even a failed 'git push' recommends to do to the users, and there was no link between how 'git pull' behaves and use of detached HEAD at all. -- 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
Re: Pull is Mostly Evil
On Fri, 2 May 2014, David Kastrup wrote: Date: Fri, 02 May 2014 17:45:23 +0200 From: David Kastrup d...@gnu.org To: git@vger.kernel.org Subject: Re: Pull is Mostly Evil Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. so those people just need to use fetch instead of pull. This seems fairly straightforward fetch, get the data but don't integrate it pull, get the data and ff along it if possible pull with options, merge/rebase left/right based on options when ff is not possible. Pull was created with one workflow in mind, Changing it to require explcitly specifying the option (in a config, with appropriate transition, handholding) is not completly unreasonable, and given the confusion this causes, may be very reasonable. But saying that ff isn't always right, so make pull go away altogether (or don't change anything because there isn't 100% agreement on the result paralysis) doesn't seem right. It's just when the merge-left/merge-right/rebase-left/rebase-right decision kicks in that prescribing one git-pull behavior looks like a recipe for trouble. confusion at least. It's not fatal confusion, people have been using it for years after all. David Lang -- 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
Re: [PATCH v6 4/7] pull: add --merge option
On Thu, May 01, 2014 at 09:41:34PM -0500, Felipe Contreras wrote: brian m. carlson wrote: On Thu, May 01, 2014 at 07:00:05PM -0500, Felipe Contreras wrote: Also, deprecate --no-rebase since there's no need for it any more. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-pull.txt | 8 ++-- git-pull.sh| 10 +- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index 9a91b9f..767bca3 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -127,8 +127,12 @@ It rewrites history, which does not bode well when you published that history already. Do *not* use this option unless you have read linkgit:git-rebase[1] carefully. ---no-rebase:: - Override earlier --rebase. +-m:: +--merge:: + Force a merge. ++ +See `pull.mode`, `branch.name.pullmode` in linkgit:git-config[1] if you want +to make `git pull` always use `--merge`. So I'm confused here, and maybe you can enlighten me. As I read this documentation, --merge would always force a merge, like --no-ff. If so, I don't see an option to preserve the existing behavior, which is the I-don't-care-just-do-it case. If the behavior is different, then this documentation needs to be improved, I think, along with the documentation earlier in the series. I don't understand what is your point. So basically you think these should be the same? % git pull --merge --no-merge --rebase --no-rebase % git pull My point is that it's unclear to me what options I need to use to retain the current behavior (fast-forward if possible, merge otherwise) without a warning. Right now, it looks like --merge is equivalent to --no-ff, which seems silly, since we already have an option for that. So my request is that you add an option (command-line and configuration) that maintains the current behavior, or if there's already such an option, that the documentation be clear enough so that I can figure it out. Because right now, it's not. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER
Charles Bailey cbaile...@bloomberg.net writes: I claim that any platform which provides both but with differing senses is somewhat broken so I cannot see the precedence mattering much. I agree with that, and that is the reason why we shouldn't change the order all of a sudden. If it shouldn't matter, then there is only downside of a possiblity to break such an insane set-up that has been happily working by accident, without helping anybody if we change it, no? -- 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
Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER
Junio C Hamano gits...@pobox.com writes: Charles Bailey cbaile...@bloomberg.net writes: I claim that any platform which provides both but with differing senses is somewhat broken so I cannot see the precedence mattering much. I agree with that, and that is the reason why we shouldn't change the order all of a sudden. If it shouldn't matter, then there is only downside of a possiblity to break such an insane set-up that has been happily working by accident, without helping anybody if we change it, no? So,... I am inclined to queue this on top of your patch at least for now, before I go into incommunicado-mode to finish preparing -rc2. -- 8 -- Subject: [PATCH] compat/bswap.h: restore preference __BIG_ENDIAN over BIG_ENDIAN The previous commit swaps the order we check the macros defined by the compiler and the system headers from the original. Since the order of check should not matter (i.e. it is insane to define both __BIG_ENDIAN and friends and BIG_ENDIAN and friends and in a conflicting way), it is the most conservative thing to do not to change it. Signed-off-by: Junio C Hamano gits...@pobox.com --- compat/bswap.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/compat/bswap.h b/compat/bswap.h index f08a9fe..c4293db 100644 --- a/compat/bswap.h +++ b/compat/bswap.h @@ -101,18 +101,18 @@ static inline uint64_t git_bswap64(uint64_t x) #undef ntohll #undef htonll -#if defined(BYTE_ORDER) defined(LITTLE_ENDIAN) defined(BIG_ENDIAN) - -# define GIT_BYTE_ORDER BYTE_ORDER -# define GIT_LITTLE_ENDIAN LITTLE_ENDIAN -# define GIT_BIG_ENDIAN BIG_ENDIAN - -#elif defined(__BYTE_ORDER) defined(__LITTLE_ENDIAN) defined(__BIG_ENDIAN) +#if defined(__BYTE_ORDER) defined(__LITTLE_ENDIAN) defined(__BIG_ENDIAN) # define GIT_BYTE_ORDER __BYTE_ORDER # define GIT_LITTLE_ENDIAN __LITTLE_ENDIAN # define GIT_BIG_ENDIAN __BIG_ENDIAN +#elif defined(BYTE_ORDER) defined(LITTLE_ENDIAN) defined(BIG_ENDIAN) + +# define GIT_BYTE_ORDER BYTE_ORDER +# define GIT_LITTLE_ENDIAN LITTLE_ENDIAN +# define GIT_BIG_ENDIAN BIG_ENDIAN + #else # define GIT_BIG_ENDIAN 4321 -- 2.0.0-rc1-355-gd6d6511 -- 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
Re: Pull is Evil
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
W. Trevor King wrote [1]:
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command without thinking it through all the way. I'm also
not used to reading Git's output and using 'reset --hard' with the
reflog to reverse changes. Instead of trusting me to only say
what I mean or leaving me to recover from mistakes, please tell me
what's about to change and let me opt out if I've changed my
mind.”
Unfortunately those folks by definition wouldn't know about the
--prompt option.
But once such folks are identified, you just have to convince them
(once) to set the pull.prompt config. That's a lot easier than
convincing them (for every pull) to set the appropriate ff flag.
It wouldn't matter if by the default non-fast-forward merges are
rejected.
It would matter if you [only wanted] them making non-fast-forward
merges (e.g. for explicitly-merged topic branches).
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much that
matters is probably best left up to the projects themselves and not
decided in Git code. I like having a place to explain why a feature
is useful and has been included in projects I maintain.
And just as they can do pull.promot = true, they can do pull.mode =
fetch-only.
Why would you run a fetch-only pull instead of running 'git fetch'? I
think it would make more sense to have 'pull.mode = none' with which
'git pull …' turns into a no-op suggesting an explicit
fetch/{merge|rebase}. Having something like that available would
help with the training issue that pull.prompt was addressing.
Cheers,
Trevor
[1]: With David Kastrup's only wanted typo fix.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: Pull is Evil
Junio C Hamano gits...@pobox.com writes: Marc Branchaud marcn...@xiplink.com writes: I may be mistaken, but I think git pull evolved to try to address the detached-HEAD risk (at least in part). You are totally mistaken. git pull was part of the things to make git usable by Linus before 1.0 release, and matches the integrator workflow perfectly well. The detached HEAD came much much later. The issue we are discussing with git pull is that if a non integrator does a git pull from the upstream, in order to push the result of integrating the local work with it back to the upstream, by default git pull creates a merge in a direction that is wrong when seen in the first-parent chain is the trunk point of view. One way to solve that _might_ be to use the detached HEAD as you illustrated in your long-hand in the thread that had Brian's example, but that is not even a failed 'git push' recommends to do to the users, and there was no link between how 'git pull' behaves and use of detached HEAD at all. One other thing to keep in mind is that the first-parent view itself is fairly new, compared to git pull (and it is even newer than detached HEAD IIRC, but I do not think detached HEAD has much to do with the current 'git pull' is often harmful confusion, except that it may be one ingredient for a possible solution). Back when we started A simple CVS/SVN like workflow can be done by cycles of 'git pull', do your work, 'git push', the order of parents in resulting merges was not an issue. I am only saying these to give people the historical background to discuss a possible solution. I am not saying that it is a possible solution to discourage the first-parent chain is the mainline of the development world view. -- 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
Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER
On Fri, May 02, 2014 at 12:43:32PM -0700, Junio C Hamano wrote: So,... I am inclined to queue this on top of your patch at least for now, before I go into incommunicado-mode to finish preparing -rc2. Yes, I'd agree with that. -- 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
Re: Pull is Mostly Evil
Felipe Contreras felipe.contre...@gmail.com writes: Stepping back even further, and thinking what is different between these two pulls, we notice that the first one is pulling from the place we push back to. Perhaps a way to solve this issue, without having to introduce a new 'git update' and updating the tutorials, may be disallow fetch+merge by default only when pulling from the place the result is going to be pushed back to? Which is basically essentially the same as not specifying anything, or rather, running `git pull` without arguments. I cannot tell if you are agreeing or disagreeing, and with what. Using the special case 'git pull' without arguments heuristics would take us back to the old jc/pull-training-wheel patch http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=230856 which we agreed to drop in http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365 to favor the old series you did with pull.mode, and we rejected that patch in $gmane/230856 for a sound reason, I would think. You are pulling from the place the result is going to be pushed back to is different from 'git pull' was run without arguments. In the pumpking example in the message you are responding to: When he becomes in charge of producing a new 'maint' (in his original, he says 'maintenance-branch'), he first does this: $ git checkout maint $ git pull --ff-only [ origin maint ] the heuristics would trigger the safety only when the optional origin maint are not given, but we do have enough information to see git pull origin maint (with where from and what to pull explicitly specified on the command line) falls into the case where the user needs protection, don't we? Also, with the triangular push configuration, git pull without argument will fetch from one place that is different from where the current branch is going to pushed to, so that heuristics would not work at all. So... -- 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
Re: [PATCH v6 4/7] pull: add --merge option
brian m. carlson wrote: My point is that it's unclear to me what options I need to use to retain the current behavior (fast-forward if possible, merge otherwise) without a warning. The current behavior is to always merge (ff or otherwise), just what `git merge` would do, so `git pull --merge`. I don't see what's confusing about 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
Re: [PATCH 7/8] CodingGuidelines: on comparison
On Fri, May 02, 2014 at 11:18:34AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Wed, Apr 30, 2014 at 02:45:11PM -0700, Junio C Hamano wrote: See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126 Signed-off-by: Junio C Hamano gits...@pobox.com Don't you often complain about submitters referencing a discussion in a commit message without providing some context or summary? Yes, but the summary of the discussion would be identical to the new text added by the patch to the documentation tree in this case, so I didn't find a good introductory text before See $URL. Perhaps This comes up from time to time. See $URL for the original discussion. but I do not know if that is much better. I meant something even less in-depth. Your message says only on comparison, and I did not even know what this in your sentence above would mean until I followed the link. There are arguments for writing a conditional as a b rather than b a, or vice versa. Let's give guidance on which we prefer. Not a big deal, but I think it is easy when you have just written the patch to forget that a reviewer or a reader of git log six months have no has no context at all. -Peff -- 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
Re: [PATCH 1/8] CodingGuidelines: typofix
On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote: But let's follow this one: http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20callcmpt=q which seems to say that with 'e' is more common. Grammar by democracy. ;) *1* To Americans, the form with 'e' is abomination. Wikipedia claims that (1) without 'e' is in legal and (2) with 'e' in other contexts in British (this particular one is a non-legal use), and (3) both are equally acceptable in non-legal contexts in Austraria and Canada. That is what I found most interesting about the discussion. The reason I bothered to look it up and say something is that as an American, I would without a doubt spell it with the e, contradicting what I found online. Oh well. -Peff -- 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
Re: [PATCH v6 4/7] pull: add --merge option
On Fri, May 02, 2014 at 03:14:44PM -0500, Felipe Contreras wrote: brian m. carlson wrote: My point is that it's unclear to me what options I need to use to retain the current behavior (fast-forward if possible, merge otherwise) without a warning. The current behavior is to always merge (ff or otherwise), just what `git merge` would do, so `git pull --merge`. I don't see what's confusing about that. When the documentation says Forces a merge without any clarifying statement, that implies to me that it always creates a new commit. I'm certain that I'm not the only person who is going to think that. Could you please clarify the documentation for --merge and pull.mode to avoid confusing users? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH 7/8] CodingGuidelines: on comparison
Jeff King p...@peff.net writes: I meant something even less in-depth. Your message says only on comparison, and I did not even know what this in your sentence above would mean until I followed the link. There are arguments for writing a conditional as a b rather than b a, or vice versa. Let's give guidance on which we prefer. Not a big deal, but I think it is easy when you have just written the patch to forget that a reviewer or a reader of git log six months have no has no context at all. Thanks; I'll steal that one. -- 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
Re: Pull is Evil
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much that
matters is probably best left up to the projects themselves and not
decided in Git code.
Let's make some fake numbers to see around how much this would matter.
The amount of people that are not used to Git could be around 60%.
Of these, the amount that would be doing integration is probably 30%, as
those tasks would be relegated to more advanced users. A project that
lets non-advanced users to integration probably wouldn't care if the
merges are fast-forward or not, but let's say 10% of them do. That makes
3%.
On the other hand, user might do merges when trying to bring their local
repositories up-to-date, let's say 100% of them do. Of those, the ones
in a project that doesn't want fast-forward merges is probably 10%. That
makes 10%. However, such projects wouldn't want them merging
'origin/master' to 'master', but 'topic' to 'master', so they shouldn't
be using `git pull` anyway, but for the sake of argument let's say that
they do.
That would make around 8%, and 6% of those wouldn't be using `git pull`
anyway.
So no, for all intents and purposes it doesn't matter. I would rather
concentrate on the issue more than 90% of the users face.
And just as they can do pull.promot = true, they can do pull.mode =
fetch-only.
Why would you run a fetch-only pull instead of running 'git fetch'? I
think it would make more sense to have 'pull.mode = none' with which
'git pull …' turns into a no-op suggesting an explicit
fetch/{merge|rebase}. Having something like that available would
help with the training issue that pull.prompt was addressing.
I fail to see how training them to do this:
% git config --global pull.mode none
% git pull
% git fetch
% git merge --no-ff
Is preferable than training them to do:
% git pull --no-ff
--
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
Re: [PATCH v6 1/7] pull: rename pull.rebase to pull.mode
On 2014-05-01 20:00, Felipe Contreras wrote: Also 'branch.name.rebase' to 'branch.name.pullmode'. This way we can add more modes and the default can be something else, namely it can be set to merge-ff-only, so eventually we can reject non-fast-forward merges by default. The old configurations still work, but get deprecated. s/get/are/ Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/config.txt | 39 ++- Documentation/git-pull.txt | 2 +- branch.c | 4 ++-- builtin/remote.c | 14 -- git-pull.sh| 31 +-- t/t3200-branch.sh | 40 t/t5601-clone.sh | 4 ++-- 7 files changed, 88 insertions(+), 46 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index c26a7c8..c028aeb 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -708,7 +708,7 @@ branch.autosetupmerge:: branch.autosetuprebase:: When a new branch is created with 'git branch' or 'git checkout' that tracks another branch, this variable tells Git to set - up pull to rebase instead of merge (see branch.name.rebase). + up pull to rebase instead of merge (see branch.name.pullmode). When `never`, rebase is never automatically set to true. When `local`, rebase is set to true for tracked branches of other local branches. Should branch.autosetuprebase be replaced with a new branch.autosetupmode setting? @@ -764,15 +764,17 @@ branch.name.mergeoptions:: option values containing whitespace characters are currently not supported. -branch.name.rebase:: - When true, rebase the branch name on top of the fetched branch, - instead of merging the default branch from the default remote when - git pull is run. See pull.rebase for doing this in a non - branch-specific manner. +branch.name.pullmode:: + When git pull is run, this determines if it would either merge or + rebase the fetched branch. To me this sentence implies that 'rebase' would rebase the fetched branch onto HEAD, when it's actually the other way around. The possible values are 'merge', + 'rebase', and 'rebase-preserve'. While the name 'merge' is mostly self-explanatory, I think it needs further clarification: Does 'merge' imply --no-ff? Or --ff? Or the value of merge.ff? Which side will be the first parent? Similarly, 'rebase' could use some clarification: * the local branch is rebased onto the pulled branch, not the other way around * it doesn't simply do 'git rebase FETCH_HEAD' -- it also walks the reflog of the upstream ref until it finds an ancestor of the local branch See pull.mode for doing this in a + non branch-specific manner. I find this sentence to be a bit unclear and would prefer something like: Defaults to the value of pull.mode. + - When preserve, also pass `--preserve-merges` along to 'git rebase' - so that locally committed merge commits will not be flattened - by running 'git pull'. + When 'rebase-preserve', also pass `--preserve-merges` along to + 'git rebase' so that locally committed merge commits will not be + flattened by running 'git pull'. ++ + It was named 'branch.name.rebase' but that is deprecated now. To me this sentence implies that .rebase was simply renamed to .pullmode with no other changes. I'd prefer something like this: branch.name.rebase:: Deprecated in favor of branch.name.pullmode. (Same goes for pull.rebase.) + *NOTE*: this is a possibly dangerous operation; do *not* use it unless you understand the implications (see linkgit:git-rebase[1] @@ -1881,15 +1883,18 @@ pretty.name:: Note that an alias with the same name as a built-in format will be silently ignored. -pull.rebase:: - When true, rebase branches on top of the fetched branch, instead - of merging the default branch from the default remote when git - pull is run. See branch.name.rebase for setting this on a - per-branch basis. +pull.mode:: + When git pull is run, this determines if it would either merge or + rebase the fetched branch. The possible values are 'merge', + 'rebase', and 'rebase-preserve'. See branch.name.pullmode for doing + this in a non branch-specific manner. ++ + When 'rebase-preserve', also pass `--preserve-merges` along to + 'git rebase' so that locally committed merge commits will not be + flattened by running 'git pull'. ++ + - When preserve, also pass `--preserve-merges` along to 'git rebase' - so that locally committed merge commits will not be flattened - by running 'git pull'. The default value should be documented. Also, rather than copy+paste the
Re: [PATCH 1/8] CodingGuidelines: typofix
Jeff King wrote: On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote: But let's follow this one: http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20callcmpt=q which seems to say that with 'e' is more common. Grammar by democracy. ;) Languages are a democracy. There's no authority that decides if unibrow should become part of the English language. We all do. -- 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
[PATCH 9/8] CodingGuidelines: on splitting a long line
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/CodingGuidelines | 55 ++
1 file changed, 55 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 02ca67c..4dd07c3 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -249,6 +249,61 @@ For C programs:
Just do not mix styles in the same part of the code and mimic
existing styles in the neighbourhood.
+ - There are two schools of thought when it comes to splitting a long
+ logical line into multiple lines. Some people push the second and
+ subsequent lines far enough to the right with tabs and align them:
+
+if (the_beginning_of_a_very_long_expression_that_has_to ||
+ span_more_than_a_single_line_of ||
+ the_source_text) {
+...
+
+ while other people prefer to align the second and the subsequent
+ lines with the column immediately inside the opening parenthesis,
+ with tabs and spaces, following our tabstop is always a multiple
+ of 8 convention:
+
+if (the_beginning_of_a_very_long_expression_that_has_to ||
+ span_more_than_a_single_line_of ||
+ the_source_text) {
+...
+
+ Both are valid, and we use both. Again, just do not mix styles in
+ the same part of the code and mimic existing styles in the
+ neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+ a binary operator, so that the result looks like a parse tree when
+ you turn your head 90-degrees counterclockwise:
+
+if (the_beginning_of_a_very_long_expression_that_has_to
+ || span_more_than_a_single_line_of_the_source_text) {
+
+ while other people prefer to leave the operator at the end of the
+ line:
+
+if (the_beginning_of_a_very_long_expression_that_has_to ||
+ span_more_than_a_single_line_of_the_source_text) {
+
+ Both are valid, but we tend to use the latter more, unless the
+ expression gets fairly complex, in which case the former tends to
+ be easier to read. Again, just do not mix styles in the same part
+ of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+ equal, it is preferrable to split after the operator at higher
+ level in the parse tree. That is, this is more preferrable:
+
+ if (a_very_long_variable * that_is_used_in +
+ a_very_long_expression) {
+ ...
+
+ than
+
+ if (a_very_long_variable *
+ that_is_used_in + a_very_long_expression) {
+ ...
+
- Some clever tricks, like using the !! operator with arithmetic
constructs, can be extremely confusing to others. Avoid them,
unless there is a compelling reason to use them.
--
2.0.0-rc1-355-gd6d6511
--
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
Re: Pull is Mostly Evil
David Lang da...@lang.hm writes: On Fri, 2 May 2014, David Kastrup wrote: It's just when the merge-left/merge-right/rebase-left/rebase-right decision kicks in that prescribing one git-pull behavior looks like a recipe for trouble. confusion at least. It's not fatal confusion, people have been using it for years after all. It's one of the most frequent causes for educating newcomers what they have been doing wrong in the LilyPond project. Including the occasional blunder from experienced people who did not notice that they got a non-ff merge as a mergeday present. It's one of the main things putting new contributors on edge and causing anxiety about messing up again. -- David Kastrup -- 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
Re: [PATCH 1/8] CodingGuidelines: typofix
Felipe Contreras felipe.contre...@gmail.com writes: Jeff King wrote: On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote: But let's follow this one: http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20callcmpt=q which seems to say that with 'e' is more common. Grammar by democracy. ;) Languages are a democracy. There's no authority that decides if unibrow should become part of the English language. We all do. Well, and the U.S. justice system rather supports the hyphenation judge- mental. -- David Kastrup -- 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
very important message.
Firstly, I apologize for sending you this sensitive information via E-mail. In my banking department we discovered an abandoned sum of 10,000,000.00$ [Ten Million Dollars Only) in an account that belongs to one of our Foreign customers who unfortunately lost his life with his entire family on his way to the Airport of Heathrow. Since we got information about his death, we have been expecting his next of kin or relatives to come over and claim his funds because we cannot release it unless somebody applies for it as Next of kin or relation to the deceased as indicated in our banking guidelines. We want you to come in as the Next Of Kin, all needed cooperation to make the claims will be given to you by us. If you are interested kindly let us have the below information and I will give you more details. 1. Full name 2: Your private telephone and Fax numbers. 3. Occupations and Nationality. 4. Date of Birth 5, Present Location 6.Home Address We are offering 30% of the total sum to you as our partner. We will discuss much in details when I receive your response. Thanks and good luck to us. Email:philippepr...@bnpparibasbnk.com Best regards, Mr..Philippe Price. -- 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
Re: A failing attempt to use Git in a centralized environment
Hi. Problem #6: push - reject - pull - push sequence sometimes transforms into a loop with several iterations and doesn't add happiness. As far as I undestand, this is the most annoying thing. In git (like other distributed systems), you cannot push your changes unless you merge them with a very last version of the whole repository. I think the only good way to use git in a team with more than a very few persons is to switch to pull-request based workflow, which does not require users to update to push their changes. Then their changes are merged to master either by a human integrator or by a tool (gitorious, github, stash, gerrit etc.). I think it can be even as little as 'update' hook, thich is triggered when user pushes to branch like 'inbox/bob' and tries to merge the branch to master. The only issue I can see with it is that does not provide a way to specify meaningful merge message. Btw, then the problem#2 is not a problem, because the merge done by user does not yet produce the commit to be added to master, but just prepares more recent version - to resolves conflicts or check how the changes work against newer codebase. One more merge is still performed by the server, and parent order is correct: master =+===+==2 \ \/ your copy +===1==+ -- Max -- 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
Re: [PATCH 9/8] CodingGuidelines: on splitting a long line
On Fri, May 02, 2014 at 01:51:55PM -0700, Junio C Hamano wrote: + - When splitting a long logical line, with everything else being + equal, it is preferrable to split after the operator at higher dict.org says that it should be preferable, not preferrable. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
smudge/clean filters and SHA1 hashes
Hi All, surprisingly, searching this list and by way of Google I cannot find an answer to a simple question: In presence of smudge/clean filters which SHA1 hash (clean content or smudged content) gets stored in the repository? Thanks, --Leo-- P.S. Very similar question [1] was posted here in 2012 but went unanswered. [1] http://git.661346.n2.nabble.com/workflow-clarification-sha1-merge-patch-diff-ws-smudge-clean-td7561818.html -- 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
Re: smudge/clean filters and SHA1 hashes
On Fri, May 2, 2014 at 2:05 PM, Leo Razoumov slonik...@gmail.com wrote: surprisingly, searching this list and by way of Google I cannot find an answer to a simple question: In presence of smudge/clean filters which SHA1 hash (clean content or smudged content) gets stored in the repository? The clean version is used to obtain the SHA-1. -- 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
Re: Pull is Mostly Evil
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Stepping back even further, and thinking what is different between these two pulls, we notice that the first one is pulling from the place we push back to. Perhaps a way to solve this issue, without having to introduce a new 'git update' and updating the tutorials, may be disallow fetch+merge by default only when pulling from the place the result is going to be pushed back to? Which is basically essentially the same as not specifying anything, or rather, running `git pull` without arguments. I cannot tell if you are agreeing or disagreeing, and with what. I'm agreeing that 'git pull repo branch' is different than 'git pull', and 'git pull' is the problem. I'm not certain about 'git pull repo', but I think that probably shouldn't change either. Using the special case 'git pull' without arguments heuristics would take us back to the old jc/pull-training-wheel patch http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=230856 If you mean adding back the 'test $# = 0', then yes, if you mean going back to 'pull.rebase=false' to force merges (and a bunch of other stuff), then no. which we agreed to drop in http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365 to favor the old series you did with pull.mode, and we rejected that patch in $gmane/230856 for a sound reason, I would think. Because the 'pull.mode=merge' mode option was simply sensible. You are pulling from the place the result is going to be pushed back to is different from 'git pull' was run without arguments. In the pumpking example in the message you are responding to: When he becomes in charge of producing a new 'maint' (in his original, he says 'maintenance-branch'), he first does this: $ git checkout maint $ git pull --ff-only [ origin maint ] the heuristics would trigger the safety only when the optional origin maint are not given, but we do have enough information to see git pull origin maint (with where from and what to pull explicitly specified on the command line) falls into the case where the user needs protection, don't we? I think 'git pull' and 'git pull origin maint' are different, regardless of the fact that origin/maint is the upstream. In the former I would expect 'maint' to be merged to 'origin/maint', in the latter I would expect 'origin/maint' to be merged into 'maint'. And if the user has specified that he wants to merge 'origin/maint' into 'maint', I don't see why a non-fast-forward should fail. Also, with the triangular push configuration, git pull without argument will fetch from one place that is different from where the current branch is going to pushed to, so that heuristics would not work at all. I think that's irrelevant. Both the upstream and publish tracking branches don't matter when the user has specifically asked for a branch to be pulled. -- 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
Re: Pull is Evil
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much
that matters is probably best left up to the projects themselves
and not decided in Git code.
Let's make some fake numbers to see around how much this would matter.
The point isn't that this is a huge flaw, the point is that we should
be able to configure Git to match sane workflows. Saying “that's
unlikely to happen” doesn't solve the problem that some newcomers have
trouble matching their project's desired workflow.
So no, for all intents and purposes it doesn't matter. I would rather
concentrate on the issue more than 90% of the users face.
You don't have to concentrate on it, because I'm willing to write up
the patch, I'm just trying to find a consensus spec before writing the
patch. If you don't have strong feelings about a pull.prompt
proposal, I won't mind ;). I just don't want to write it up and
*then* hear “that's a terrible idea, you should have just done $x.”.
And just as they can do pull.promot = true, they can do pull.mode =
fetch-only.
Why would you run a fetch-only pull instead of running 'git fetch'? I
think it would make more sense to have 'pull.mode = none' with which
'git pull …' turns into a no-op suggesting an explicit
fetch/{merge|rebase}. Having something like that available would
help with the training issue that pull.prompt was addressing.
I fail to see how training them to do this:
% git config --global pull.mode none
% git pull
% git fetch
% git merge --no-ff
Is preferable than training them to do:
% git pull --no-ff
The goal is to train them to do:
% git config --global pull.mode none
% git fetch
% git merge --no-ff
The 'git pull' (with 'none' mode) explainer just helps retrain folks
that are already using the current 'git pull' incorrectly.
The benefit is that the repeated pair of commands (fetch/merge) takes
longer to type, which gives them longer to realize that they should
think about what they're doing and abort. That's all a pull.prompt
would be doing anyway.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v6 1/7] pull: rename pull.rebase to pull.mode
Richard Hansen wrote:
On 2014-05-01 20:00, Felipe Contreras wrote:
Also 'branch.name.rebase' to 'branch.name.pullmode'.
This way we can add more modes and the default can be something else,
namely it can be set to merge-ff-only, so eventually we can reject
non-fast-forward merges by default.
The old configurations still work, but get deprecated.
s/get/are/
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/config.txt | 39 ++-
Documentation/git-pull.txt | 2 +-
branch.c | 4 ++--
builtin/remote.c | 14 --
git-pull.sh| 31 +--
t/t3200-branch.sh | 40
t/t5601-clone.sh | 4 ++--
7 files changed, 88 insertions(+), 46 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c26a7c8..c028aeb 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -708,7 +708,7 @@ branch.autosetupmerge::
branch.autosetuprebase::
When a new branch is created with 'git branch' or 'git checkout'
that tracks another branch, this variable tells Git to set
- up pull to rebase instead of merge (see branch.name.rebase).
+ up pull to rebase instead of merge (see branch.name.pullmode).
When `never`, rebase is never automatically set to true.
When `local`, rebase is set to true for tracked branches of
other local branches.
Should branch.autosetuprebase be replaced with a new
branch.autosetupmode setting?
Maybe. But if so, I think that should be done in another series.
Otherwise we'll never have a chance to change anything.
@@ -764,15 +764,17 @@ branch.name.mergeoptions::
option values containing whitespace characters are currently not
supported.
-branch.name.rebase::
- When true, rebase the branch name on top of the fetched branch,
- instead of merging the default branch from the default remote when
- git pull is run. See pull.rebase for doing this in a non
- branch-specific manner.
+branch.name.pullmode::
+ When git pull is run, this determines if it would either merge or
+ rebase the fetched branch.
To me this sentence implies that 'rebase' would rebase the fetched
branch onto HEAD, when it's actually the other way around.
Right.
This actually interesting mode of thinking:
a) git pull --rebase
We want to rebase HEAD onto @{upstream}.
b) git pull --merge
We want to merge HEAD into @{upstream}. (Why are we doing the opposite?)
c) git pull --rebase github john
We weant to rebase github/john onto HEAD. (We are doing the opposite?)
d) git pull --merge github john
We want to merge github/john into HEAD.
The possible values are 'merge',
+ 'rebase', and 'rebase-preserve'.
While the name 'merge' is mostly self-explanatory, I think it needs
further clarification: Does 'merge' imply --no-ff? Or --ff? Or the
value of merge.ff?
'pull.mode=merge' will do the same as `git merge`, I don't see where or
how it can be explained more clearly.
Which side will be the first parent?
The same as things currently are: the pulled branch into the current
branch (current branch is first parent).
We should probably change this, but that's out of scope of this series,
and hasn't been decided yet.
See pull.mode for doing this in a
+ non branch-specific manner.
I find this sentence to be a bit unclear and would prefer something
like: Defaults to the value of pull.mode.
Hmm, might make sense.
+
- When preserve, also pass `--preserve-merges` along to 'git rebase'
- so that locally committed merge commits will not be flattened
- by running 'git pull'.
+ When 'rebase-preserve', also pass `--preserve-merges` along to
+ 'git rebase' so that locally committed merge commits will not be
+ flattened by running 'git pull'.
++
+ It was named 'branch.name.rebase' but that is deprecated now.
To me this sentence implies that .rebase was simply renamed to .pullmode
with no other changes. I'd prefer something like this:
branch.name.rebase::
Deprecated in favor of branch.name.pullmode.
(Same goes for pull.rebase.)
Right.
+
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
@@ -1881,15 +1883,18 @@ pretty.name::
Note that an alias with the same name as a built-in format
will be silently ignored.
-pull.rebase::
- When true, rebase branches on top of the fetched branch, instead
- of merging the default branch from the default remote when git
- pull is run. See branch.name.rebase for setting this on a
- per-branch basis.
+pull.mode::
+ When git pull is run, this determines if it would either merge
Re: Pull is Evil
W. Trevor King wrote: On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: It would matter almost exactly zero. Some folks have explicit merge policies, and deciding how much that matters is probably best left up to the projects themselves and not decided in Git code. Let's make some fake numbers to see around how much this would matter. The point isn't that this is a huge flaw, the point is that we should be able to configure Git to match sane workflows. The point is that we are tainting a discussion about how to improve the defaults for the vast majority of users, and given Git's history, the most likely outcome is that nothing will happen, neither for the majority, nor the tiny minority. Saying “that's unlikely to happen” doesn't solve the problem that some newcomers have trouble matching their project's desired workflow. % git config --global pull.ff false Done. The goal is to train them to do: % git config --global pull.mode none % git fetch % git merge --no-ff The 'git pull' (with 'none' mode) explainer just helps retrain folks that are already using the current 'git pull' incorrectly. If you are going to train them to use a configuration, it should be: % git config --global pull.ff false -- 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
Re: Pull is Mostly Evil
On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote: Junio C Hamano wrote: If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push does not fast-forward. In addition to barf when it's not a fast-forward, such command can switch the parents, so it appears 'maint' was merged to 'origin/maint'. Many people have complained about this order. I realize this has veered off into talking about an update command, and not necessarily pull, but since there a lot of proposals floating around, I wanted to make one point: if we are going to do such a switch, let's please make it something the user explicitly turns on. One common workflow for GitHub users is to back-merge master into a topic, because they want the final integrated version on the topic branch. That lets it get review, run tests, and even get test-deployed from there before merging to master (and then when it does merge to master, we know the result will be a trivial merge). This workflow helps spread out the load (there is no central integration person or script, and the merge itself becomes a possible part of the review/test cycle). Some projects will do this by rebasing the topic, but that has its own complications (like making collaboration harder because the commits are being frequently rewritten). Such users are going to run git pull origin master or just git pull to get that merge. A switch to disallowing non-ff is going to disrupt that workflow. I think we can live with that, as they should be able to stop and say no, my workflow wants these merges, set a config variable, and be done. But I think that is the same moment they should probably be deciding on whether their workflow wants regular or reverse merges. And I do not think the decision between the two has an obvious split over which is better. So it makes sense to me to take the opportunity when the user is thinking about their workflow to have them specify one or the other. -Peff -- 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
pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)
On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: It would matter almost exactly zero. Some folks have explicit merge policies, and deciding how much that matters is probably best left up to the projects themselves and not decided in Git code. Let's make some fake numbers to see around how much this would matter. The point isn't that this is a huge flaw, the point is that we should be able to configure Git to match sane workflows. The point is that we are tainting a discussion about how to improve the defaults for the vast majority of users I've renamed this sub-thread (which started around $gmane/247835) to avoid potential confusion/dilution. The goal is to train them to do: % git config --global pull.mode none % git fetch % git merge --no-ff Sticking to my 'no-ff' topic branch example, this should have been: git merge --no-ff remote branch I want folks to use --ff-only when pulling their default upstream. The 'git pull' (with 'none' mode) explainer just helps retrain folks that are already using the current 'git pull' incorrectly. If you are going to train them to use a configuration, it should be: % git config --global pull.ff false I don't want all pulls to be --no-ff, only pulls from topic branches. I think adding a prompt or making the integration a two-step fetch/merge are both ways to jog a user into consciously evaluating their actions. I don't see how a changing the default single-step pull strategy (whatever it is) will. I also don't look forward to explaining an adaptive strategy that tries to get my workflow right without command-line ff options to folks on their first day using Git. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: smudge/clean filters and SHA1 hashes
Leo Razoumov slonik...@gmail.com writes: In presence of smudge/clean filters which SHA1 hash (clean content or smudged content) gets stored in the repository? You are cleaning cruft in the contents before the contents are hashed to compute the object name. The point is to keep clean objects in the object database, protected from dirty reality in the working tree (which you instanciate by applying the smudge filter to dirty the clean object in the ideal world). The crlf conversion works exactly the same way. For portability, you keep a version terminated with LF in the object database and that is what is hashed to compute the blob object name, but we export with CRLF line endings for a working tree that wants files whose lines are terminated that way. -- 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
BUG or FEATURE? Use of '/' in branch names
According to https://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html a '/' is character to use in a branch name. git imposes the following rules on how references are named: 1. They can include slash / for hierarchical (directory) grouping, but no slash-separated component can begin with a dot . or end with the sequence .lock. git-flow, for example, uses it extensively to prefix branches with 'release/', 'bugfix/', 'hotfix/' etc. However, I just ran into the following problem $git init Initialized empty Git repository in /home/keith/play/bug2/.git/ $touch a $git add a $git commit -m C1 [master (root-commit) d569d5b] C1 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 a $git checkout -b hotfix Switched to a new branch 'hotfix' $git checkout -b hotfix/b2 error: unable to resolve reference refs/heads/hotfix/b2: Not a directory fatal: Failed to lock ref for update: Not a directory $ The problem arises when a branch already exists with a name matching the stem of the new branch name. As far as I can see, this comes from the use of the branch name to create a directory under .git/refs/heads with the name 'hotfix/b2' because .git/refs/heads/hotfix already exists as a plain file. Note, however that this works $git init Initialized empty Git repository in /home/keith/play/bug3/.git/ $touch a $git add a git commit -m 'C1' [master (root-commit) 304052c] C1 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 a $git checkout -b hotfix/b1 Switched to a new branch 'hotfix/b1' $git checkout -b hotfix/b2 Switched to a new branch 'hotfix/b2' $ls .git/refs/heads/ -R .git/refs/heads/: hotfix master .git/refs/heads/hotfix: b1 b2 $ But, for the reverse reason, I can't now create the branch named 'hotfix' I can see the value in grouping branches in a directory tree under refs/heads, but wouldn't it make more sense to simply escape the '/' in the branch name so that 'hotfix/b1' is stored on disk as 'hotfix\/b1'? I found this when trying to document a branching workflow for support branches. The repositories already had branches such as 'release1', 'release2' and I wanted to add branches such as 'release1/develop', 'release2/develop', 'release1/staging', 'release2/staging' etc. Renaming the existing published branches is not an option for us, I'm afraid. -- 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
Re: Pull is Mostly Evil
Jeff King wrote: On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote: Junio C Hamano wrote: If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push does not fast-forward. In addition to barf when it's not a fast-forward, such command can switch the parents, so it appears 'maint' was merged to 'origin/maint'. Many people have complained about this order. I realize this has veered off into talking about an update command, and not necessarily pull, but since there a lot of proposals floating around, I wanted to make one point: if we are going to do such a switch, let's please make it something the user explicitly turns on. This is sensible, but with warning X will be the default in the future, just like we did with push.default = simple. One common workflow for GitHub users is to back-merge master into a topic, because they want the final integrated version on the topic branch. That lets it get review, run tests, and even get test-deployed from there before merging to master (and then when it does merge to master, we know the result will be a trivial merge). This workflow helps spread out the load (there is no central integration person or script, and the merge itself becomes a possible part of the review/test cycle). Some projects will do this by rebasing the topic, but that has its own complications (like making collaboration harder because the commits are being frequently rewritten). They can do: % git pull origin master That shouldn't revese the bases. Such users are going to run git pull origin master or just git pull to get that merge. I'd say the vast majority of users running git pull want the parents reversed, the minority that doesn't can switch to git pull origin master (or add a configuration). A switch to disallowing non-ff is going to disrupt that workflow. Only if the refuse to do git pull origin master. But I think that is the same moment they should probably be deciding on whether their workflow wants regular or reverse merges. And I do not think the decision between the two has an obvious split over which is better. Because there hasn't been enough discussion on this topic. I'm fairly certain there will be consensus once concrete proposals are properly discussed. Most likely the consensus and the proposals will be ignored and nothing will change as usual, but that's a different thing. -- 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
Re: [PATCH] Define constants for lengths of object names
On Fri, May 02, 2014 at 07:15:44AM +0700, Duy Nguyen wrote: On Fri, May 2, 2014 at 6:05 AM, Jonathan Nieder jrnie...@gmail.com wrote: I can make up for it in enthuasiasm. Please? It's something I've wanted for a long time but never found the time to do. It's definitely better in the sense that the compiler will catch new char[20] declarations for us. It's also a lot more work. It is. I'm going to start with a patch that introduces struct object_id and the fixed constants. Then I'm going to get a patch that compiles with lots of warnings, and then I'm going to fix all those warnings. Otherwise, the patch will simply be too enormous to review. I'm willing to hear other suggestions for going about this, though. No architecture was named last time if I remember correctly. But we could check sizeof(struct object_id) == 20 in a test or something. When people scream, we can pack the struct on that particular platform? Sounds like a plan. I am not aware of any architecture that has this limitation; I've worked with x86(-64)?, 32-bit PowerPC, UltraSPARC, and ARM. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Pull is Mostly Evil
From: Marc Branchaud marcn...@xiplink.com Sent: Friday, May 02, 2014 4:37 PM (Apologies for not CCing all the folks who've participated in the Pull is Evil thread -- I couldn't find a good branch of that thread for this message.) OK, so maybe git pull is just Mostly Evil. People seem to have found many different ways to make it work for them. But in reality git pull has become a chimera that confuses a large number of new users, and that experienced users either avoid entirely or customize to give them a convenient shorthand for working in their particular environment. As a tool for new git users, it just doesn't seem to be achieving its goals. I think the git project as a whole would benefit if it started to treat git pull as an advanced command, in the sense that it needs to be configured by an experienced user in order to make it correctly follow a project's workflow. Once it's configured properly, git pull is a powerful tool that gives users an easy way to do complex things. In that sense, it may be appropriate for a project to tailor git pull as it likes, then teach its own users to use the command. However, when it comes to teaching people how to use git qua git, git pull should be the last thing they learn about, because it's only after you understand various basic git concepts that you can configure git pull to do the right thing. To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. I tend to agree. The hard part is making sure folk have enough prior learning to make a choice that their will fit their real needs. It'll take quite a bit of time, but I think that if we change our attitude towards git pull and take this unconfigured-by-default approach, then in a few years the entire git ecosystem will be in a better place. M. -- Philip -- 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
Re: BUG or FEATURE? Use of '/' in branch names
Keith Derrick keith.derr...@lge.com writes: The problem arises when a branch already exists with a name matching the stem of the new branch name. ... But, for the reverse reason, I can't now create the branch named 'hotfix' All correct. Allowing '/' in branch names came about not with a careful design but was done by a happy accident, and we accepted it under the condition as long as users know that they cannot have branches D and D/F at the same time, that is fine. An obvious alternative convention you can adopt would be to use not '/' but some other separating characters (e.g. _) as your hierarchy delimiter, if you must have D and D_F at the same time. -- 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
Re: BUG or FEATURE? Use of '/' in branch names
Hi Keith, Keith Derrick wrote: $ git checkout -b hotfix Switched to a new branch 'hotfix' $ git checkout -b hotfix/b2 error: unable to resolve reference refs/heads/hotfix/b2: Not a directory fatal: Failed to lock ref for update: Not a directory $ That's an ugly message. I think we can do better. (hint hint) Longer term, I think people would like to make it possible for a 'hotfix' and 'hotfix/b2' branch to coexist, but that will take some work, and until then, git tries to be careful about enforcing the constraint that they cannot coexist. Fixing it would be complicated by the need to avoid breaking people with older versions of git when they fetch from you (what happens to the origin/hotfix and origin/hotfix/b2 remote-tracking refs on the client side?). Thanks and hope that helps, Jonathan -- 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
RE: BUG or FEATURE? Use of '/' in branch names
Keith Derrick wrote: I can see the value in grouping branches in a directory tree under refs/heads, but wouldn't it make more sense to simply escape the '/' in the branch name so that 'hotfix/b1' is stored on disk as 'hotfix\/b1'? This would be nice for remote helpers: Mercurial can have hotfix and hotifx/b1, so importing such a Mercurial repository creates problems. -- 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
[ANNOUNCE] Git v2.0.0-rc2
A release candidate Git v2.0.0-rc2 is now available for testing
at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.0.0-rc2'
tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v2.0 Release Notes (draft)
==
Backward compatibility notes
When git push [$there] does not say what to push, we have used the
traditional matching semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). In Git 2.0, the default is now the simple semantics,
which pushes:
- only the current branch to the branch with the same name, and only
when the current branch is set to integrate with that remote
branch, if you are pushing to the same remote as you fetch from; or
- only the current branch to the branch with the same name, if you
are pushing to a remote that is not where you usually fetch from.
You can use the configuration variable push.default to change
this. If you are an old-timer who wants to keep using the
matching semantics, you can set the variable to matching, for
example. Read the documentation for other possibilities.
When git add -u and git add -A are run inside a subdirectory
without specifying which paths to add on the command line, they
operate on the entire tree for consistency with git commit -a and
other commands (these commands used to operate only on the current
subdirectory). Say git add -u . or git add -A . if you want to
limit the operation to the current directory.
git add path is the same as git add -A path now, so that
git add dir/ will notice paths you removed from the directory and
record the removal. In older versions of Git, git add path used
to ignore removals. You can say git add --ignore-removal path to
add only added or modified paths in path, if you really want to.
The -q option to git diff-files, which does *NOT* mean quiet,
has been removed (it told Git to ignore deletion, which you can do
with git diff-files --diff-filter=d).
git request-pull lost a few heuristics that often led to mistakes.
The default prefix for git svn has changed in Git 2.0. For a long
time, git svn created its remote-tracking branches directly under
refs/remotes, but it now places them under refs/remotes/origin/ unless
it is told otherwise with its --prefix option.
Updates since v1.9 series
-
UI, Workflows Features
* The multi-mail post-receive hook (in contrib/) has been updated
to a more recent version from the upstream.
* git gc --aggressive learned --depth option and
gc.aggressiveDepth configuration variable to allow use of a less
insane depth than the built-in default value of 250.
* git log learned the --show-linear-break option to show where a
single strand-of-pearls is broken in its output.
* The rev-parse --parseopt mechanism used by scripted Porcelains to
parse command line options and to give help text learned to take
the argv-help (the placeholder string for an option parameter,
e.g. key-id in --gpg-sign=key-id).
* The pattern to find where the function begins in C/C++ used in
diff and grep -p have been updated to help C++ source better.
* git rebase learned to interpret a lone - as @{-1}, the
branch that we were previously on.
* git commit --cleanup=mode learned a new mode, scissors.
* git tag --list output can be sorted using version sort with
--sort=version:refname.
* Discard the accumulated heuristics to guess from which branch the
result wants to be pulled from and make sure what the end user
specified is not second-guessed by git request-pull, to avoid
mistakes. When you pushed out your 'master' branch to your public
repository as 'for-linus', use the new master:for-linus syntax to
denote the branch to be pulled.
* git grep learned to behave in a way similar to native grep when
-h (no header) and -c (count) options are given.
* git push via transport-helper interface (e.g. remote-hg) has
been updated to allow ref deletion in a way similar to the natively
supported transports.
* The simple mode is the default for git push.
* git add -u and git add -A, when run without any pathspec, is a
tree-wide operation even when run inside a subdirectory of a
working tree.
* git add path is the same as git add -A path now.
* core.statinfo configuration variable, which is a
never-advertised synonym to core.checkstat, has been removed.
* The -q option to git diff-files, which does *NOT* mean
quiet, has been removed (it told
RE: pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)
W. Trevor King wrote: I've renamed this sub-thread (which started around $gmane/247835) to avoid potential confusion/dilution. Thanks. The goal is to train them to do: % git config --global pull.mode none % git fetch % git merge --no-ff Sticking to my 'no-ff' topic branch example, this should have been: git merge --no-ff remote branch I want folks to use --ff-only when pulling their default upstream. That's proposed to be the default anyway, so they won't need it. The 'git pull' (with 'none' mode) explainer just helps retrain folks that are already using the current 'git pull' incorrectly. If you are going to train them to use a configuration, it should be: % git config --global pull.ff false I don't want all pulls to be --no-ff, only pulls from topic branches. Pulling some branch to a topic branch, or pulling a topic branch to another branch? Either way, since I think these two are different modes: 1) git pull 2) git pull origin topic Maybe it would actually make sense to have a configuration specific to 2): pull.topicmode. This way they could do pull.topicmode = merge-no-ff. Or maybe we need arguments: pull.topicargs = --merge --no-ff. -- 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
Re: Pull is Mostly Evil
From: Felipe Contreras felipe.contre...@gmail.com Sent: Friday, May 02, 2014 8:05 PM Philip Oakley wrote: From: David Kastrup d...@gnu.org Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. While the fast forward is /pretty/ uncontentious, it still maybe contentious for some. So? No defaults can please absolutely everyone, the best anybody can do is try to please the majority of people, and merging fast-forwards only does that. That assumes that doing something is better than doing nothing, which is appropriate when the costs on either side are roughly similar. However in this case, as we have essentially all agreed, there have been some bad down sides. In that case a precautionary principle is more appropriate where doing nothing (that is git pull does nothing until user configured) is better. While a shift to merging fast-forwards would reduce the cost difference, they have to be matched against the potential user confusions when comparing to all the old web miss-instructions, hence my shift away from trying to best guess a default, rather than simply suggest it as a suitable user choice. -- Felipe Contreras -- Philip -- 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
Re: Pull is Mostly Evil
On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote: They can do: % git pull origin master That shouldn't revese the bases. Then they have to remember to do that every time, no? That seems a little error-prone versus setting a config option. Such users are going to run git pull origin master or just git pull to get that merge. I'd say the vast majority of users running git pull want the parents reversed, the minority that doesn't can switch to git pull origin master (or add a configuration). I'm not sure I agree, but I don't think either of us has actual data. Most likely the consensus and the proposals will be ignored and nothing will change as usual, but that's a different thing. Is it truly necessary to make sniping comments like this at the end of each email? It _is_ being discussed right now, and these comments do nothing except irritate your readers. Please stop. -Peff -- 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
Re: BUG or FEATURE? Use of '/' in branch names
Yes, I've since found some discussion on this, and had already changed to use '-' to append the classifier. But the other problem is that I can't easily find this restriction documented anywhere - which means it comes as a suprise to people. As it stands, the documentation implies that what I tried should work. In which case, how it's been *implemented* seems to be breaking the promise of the functional specification (if you view the documentation as such). Keith On 05/02/2014 03:16 PM, Jonathan Nieder wrote: Hi Keith, Keith Derrick wrote: $ git checkout -b hotfix Switched to a new branch 'hotfix' $ git checkout -b hotfix/b2 error: unable to resolve reference refs/heads/hotfix/b2: Not a directory fatal: Failed to lock ref for update: Not a directory $ That's an ugly message. I think we can do better. (hint hint) Longer term, I think people would like to make it possible for a 'hotfix' and 'hotfix/b2' branch to coexist, but that will take some work, and until then, git tries to be careful about enforcing the constraint that they cannot coexist. Fixing it would be complicated by the need to avoid breaking people with older versions of git when they fetch from you (what happens to the origin/hotfix and origin/hotfix/b2 remote-tracking refs on the client side?). Thanks and hope that helps, Jonathan -- 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
Re: BUG or FEATURE? Use of '/' in branch names
Hi, Keith Derrick wrote: Yes, I've since found some discussion on this, and had already changed to use '-' to append the classifier. But the other problem is that I can't easily find this restriction documented anywhere - which means it comes as a suprise to people. That sounds like another serious bug (the first one was the lousy error message). The current behavior is intended, and it sounds like the documentation is lagging. Where did you expect to find information about this? Knowing that would help a lot in fixing it. (The nicest way to indicate where you expected to read about this is with a patch against the relevant file in Documentation/*.txt, of course.) Thanks again, Jonathan -- 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
Re: Pull is Mostly Evil
Hi, Philip Oakley wrote: That assumes that [git pull] doing something is better than doing nothing, which is appropriate when the costs on either side are roughly similar. I think the conversation's going around in circles. Potential next steps: a. Documentation or test patch illustrating desired behavior b. More traditional formal design doc explaining desired behavior and the thinking behind it (problem, overview of solution, alternatives rejected, complications, example, open questions). c. Implementation patch d. Someone takes an existing patch and figures out the next step toward getting it ready for application. My preference is for (a), I guess. The point being that something more concrete (code or a design doc) makes it easier to avoid talking past each other. And having something concrete to edit makes the stakes clearer so people can make it incrementally better without being distracted by unimportant parts. Thanks and hope that helps, Jonathan -- 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
[PATCH 1/3] After chdir to run grep, return to old directory
From: David Turner dtur...@twitter.com
Signed-off-by: David Turner dtur...@twitter.com
---
builtin/grep.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 69ac2d8..e9fe040 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -355,15 +355,25 @@ static void run_pager(struct grep_opt *opt, const char
*prefix)
{
struct string_list *path_list = opt-output_priv;
const char **argv = xmalloc(sizeof(const char *) * (path_list-nr + 1));
+ static char old_directory[PATH_MAX+1];
int i, status;
for (i = 0; i path_list-nr; i++)
argv[i] = path_list-items[i].string;
argv[path_list-nr] = NULL;
- if (prefix chdir(prefix))
- die(_(Failed to chdir: %s), prefix);
+
+ if (prefix) {
+ if (!getcwd(old_directory, PATH_MAX+1))
+ die(_(Failed to get cwd: %s), prefix);
+ if (chdir(prefix))
+ die(_(Failed to chdir: %s), prefix);
+ }
status = run_command_v_opt(argv, RUN_USING_SHELL);
+ if (prefix)
+ if (chdir(old_directory))
+ die(_(Failed to chdir: %s), old_directory);
+
if (status)
exit(status);
free(argv);
--
2.0.0.rc0.31.g69c1a2d
--
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
Watchman support for git
The most sigificant patch uses Facebook's watchman daemon[1] to monitor the repository work tree for changes. This makes allows git status to avoid traversing the entire work tree to find changes. This change requires libwatchman[2], a client library that I wrote for watchman. While making the watchman change, I also made a change to the index format (contributed here in a separate patch). Index integrity checking uses the same SHA1 algorithm as the rest of git; this is actually relatively slow. It's not a huge part of run-time, but since I wanted to do the same checking for the Watchman filesystem cache (which is about twice as large as the index), I decided to optimize it anyway. I switched to VMAC. VMAC is supposed to be a MAC, but there's no reason it can't be used with a fixed key as a simple integrity check. VMAC is roughly five times faster than SHA1 on my machine; This adds up to a 5% overal speed improvement on git status (depending on the structure of your repo, and about 15% on git diff --cached with no cached changes). The index format change might be less important with the split index; I haven't investigated that since at the time I wrote these patches, it didn't exist. Some numbers follow. They are on my laptop, which has 4x i5-2520M processors, 8GB of RAM, and a solid state disk. They're all tested with a hot cache. Test repository 1: Linux Linux is about 45k files in 3k directories. The average length of a filename is about 32 bytes. Git status timing: no watchman: 125ms watchman: 90ms Test repository 2: Superscience My second test repository (which is a semi-synthetic repo generated from various Twitter internal repos) is somewhat larger than this, and gets a correspondingly larger improvement. It is about 65k files in 20k directories; the average length of a filename is 67 bytes. Git status timing: no watchman, index version 4: 370 ms no watchman, index version 5: 365 ms watchman, index version 4: 170 ms watchman, index version 5: 165 ms [1] https://github.com/facebook/watchman [2] https://github.com/twitter/libwatchman -- 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
Re: Pull is Mostly Evil
Philip Oakley wrote: From: Felipe Contreras felipe.contre...@gmail.com So? No defaults can please absolutely everyone, the best anybody can do is try to please the majority of people, and merging fast-forwards only does that. That assumes that doing something is better than doing nothing, When doing something is better for the vast majority of people, that's what should be done by default, unless the results are catastrophic for the minority. Since doing something is not catastrophic to the minority, it follows that the default should be to do something. It's a simple as 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
Re: Pull is Mostly Evil
Jeff King wrote: On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote: They can do: % git pull origin master That shouldn't revese the bases. Then they have to remember to do that every time, no? That seems a little error-prone versus setting a config option. Yes. However, since not many people do this, and they don't do it that often that's not a big deal. It's much more important to fix the issue the vast majority of users face constantly. Such users are going to run git pull origin master or just git pull to get that merge. I'd say the vast majority of users running git pull want the parents reversed, the minority that doesn't can switch to git pull origin master (or add a configuration). I'm not sure I agree, but I don't think either of us has actual data. Do you want me to go dig in the mailing list and point you to the endless discussions? I assure you, if this is not changed, we will have this discussion again. Most likely the consensus and the proposals will be ignored and nothing will change as usual, but that's a different thing. Is it truly necessary to make sniping comments like this at the end of each email? It _is_ being discussed right now, and these comments do nothing except irritate your readers. Please stop. And it has been discussed before. If history is any indication, it will be discussed again. -- 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
Re: [PATCH v6 1/7] pull: rename pull.rebase to pull.mode
On 2014-05-02 17:12, Felipe Contreras wrote: Richard Hansen wrote: Should branch.autosetuprebase be replaced with a new branch.autosetupmode setting? Maybe. But if so, I think that should be done in another series. Otherwise we'll never have a chance to change anything. Sure. The possible values are 'merge', + 'rebase', and 'rebase-preserve'. While the name 'merge' is mostly self-explanatory, I think it needs further clarification: Does 'merge' imply --no-ff? Or --ff? Or the value of merge.ff? 'pull.mode=merge' will do the same as `git merge`, I don't see where or how it can be explained more clearly. How about: branch.name.pullmode:: Determines how 'git pull' integrates the fetched branch into branch name. Defaults to the value of `pull.mode`. Supported values: + -- `merge`::: Merge the fetched branch into name. See also `merge.ff`. `rebase`::: Find the point at which name forked from the fetched branch (see the `--fork-point` option of linkgit:git-merge-base[1]), then rebase the commits between the fork point and branch name onto the fetched branch. `rebase-preserve`::: Like `rebase` but passes `--preserve-merges` to 'git rebase'. -- + *NOTE*: `rebase` and `rebase-preserve` are potentially dangerous; do *not* use them unless you understand the implications (see linkgit:git-rebase[1] for details). pull.mode:: See `branch.name.pullmode`. Defaults to `merge`. Which side will be the first parent? The same as things currently are: the pulled branch into the current branch (current branch is first parent). This was a rhetorical question -- I was trying to point out that the current behavior should be documented. We should probably change this, but that's out of scope of this series, and hasn't been decided yet. Agreed. If this series is merged, a future series could add a 'merge-there' pull mode. Also, rather than copy+paste the description from branch.name.pullmode, I'd prefer a brief reference. For example: pull.mode:: See branch.name.pullmode. Defaults to 'merge'. I'd say pull.mode is the important one. Either way works for me. How about this: branch.name.pullmode:: Overrides the value of `pull.mode` for branch name. pull.mode:: Determines how 'git pull' integrates the fetched branch into the current branch. Supported values: + -- `merge`::: (default) Merge the fetched branch into the current branch. See also `merge.ff`. `rebase`::: Find the point at which the current branch forked from the fetched branch (see the `--fork-point` option of linkgit:git-merge-base[1]), then rebase the commits between the fork point and the current branch onto the fetched branch. `rebase-preserve`::: Like `rebase` but passes `--preserve-merges` to 'git rebase'. -- + *NOTE*: `rebase` and `rebase-preserve` are potentially dangerous; do *not* use them unless you understand the implications (see linkgit:git-rebase[1] for details). -Richard -- 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
Re: pull.prompt or other way to slow/disable 'git pull'
On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
The 'git pull' (with 'none' mode) explainer just helps retrain folks
that are already using the current 'git pull' incorrectly.
If you are going to train them to use a configuration, it should be:
% git config --global pull.ff false
I don't want all pulls to be --no-ff, only pulls from topic branches.
Pulling some branch to a topic branch, or pulling a topic branch to
another branch?
The latter. Here's a more detailed list:
1. HEAD: an integration branch (master, maint, …)
target: @{upstream}, branch.*.pushremote, and other mirrors
my preferred integration mode: ff-only merge the target
2. HEAD: an integration branch
target: a *different* branch (e.g. maint or feature-x, but not
origin/master or jdoe/master, if HEAD is master)
my preferred integration mode: no-ff merge the target into HEAD.
3. HEAD: a topic branch (e.g. feature-x)
target: a collaborating topic branch (jdoe/feature-x)
my preferred integration mode: ff-only merge the target
4. HEAD: a topic branch (e.g. feature-x)
target: a related topic branch (e.g. jdoe/feature-y) or integration
branch updates used by my feature-x
my preferred integration mode: rebase feature-x onto the target
Cases 1 and 2 can usually be distinguished by comparing the
checked-out branch with the branch portion of the remote-tracking
reference), but for folks developing in master, jdoe/master may be a
feature branch (case 2) not a mirror of the maintenance branch (case
1).
Cases 1 and 3 are the same idea, with any feature branch running long
enough to get collaborators being indistinguishable from an
integration branch except that the latter will eventually be merged
(or dropped) and deleted.
In the event of non-trivial merge conflicts in case 2, I sometimes
rebase the target onto HEAD and no-ff merge the resulting target'. On
the other hand, sometimes rebasing is not an option. For example, if
I want to merge the target into both master and maint, but master
contains a conflicting commit A:
-o---o---A---o---B master
|\
| o---o---C maint
\
o---D target
Rebasing would drag A into maint at F:
-o---o---A---o---B---E master
\ \ /
\ o---D'--- target'
\ \
o---o---C---F maint
And I don't want both the pre- and post-rebase versions in my history
at G:
-o---o---A---o---B---E---G master
|\ \ / /
| \ o---D'--- / target'
| \ /
| o---o---C---F maint
\ /
o---D target
So I'd just deal with a complicated merge at E:
-o---o---A---o---B---E---G master
|\ / /
| o---D / target
\ \ /
o---o---C---F-- maint
Case 4 has similar caveats, since you don't want to rebase feature-x
on top of jdoe/feature-y if there are already other branches based on
the current feature-x that can't (or won't) be rebased.
Either way, since I think these two are different modes:
1) git pull
2) git pull origin topic
Maybe it would actually make sense to have a configuration specific to
2): pull.topicmode.
I think it makes more sense to just use merge/rebase explicitly, and
not try and bundle all of this complication into something that *also*
fetches. Unfortunately, there's currently no finger-breaker to help
compulsive pull users break the habit or keep novices from starting.
Adding more elaborate handling to pull just pushes back the point
where you reach something that is pretty much impossible to resolve
automatically (like my case 2 caveat). When that happens, it would be
nice to have a workflow independent way to calm the pull-happy user
(e.g. pull.mode=none, or pull.prompt=true) while they learn to
explicitly use fetch/{merge|rebase} or more careful pulls.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
[PATCH] completion: move out of contrib
These have been stable and widely used for quite a long time, they even
have tests outside of the contrib area, and most distributions ship
them, so they can be considered part of the core already.
Let's move them out of contrib and install them by default.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Makefile | 5 -
{contrib/completion = shared}/git-completion.bash | 0
{contrib/completion = shared}/git-completion.zsh | 0
{contrib/completion = shared}/git-prompt.sh | 0
t/t9902-completion.sh | 2 +-
t/t9903-bash-prompt.sh | 2 +-
6 files changed, 6 insertions(+), 3 deletions(-)
rename {contrib/completion = shared}/git-completion.bash (100%)
rename {contrib/completion = shared}/git-completion.zsh (100%)
rename {contrib/completion = shared}/git-prompt.sh (100%)
diff --git a/Makefile b/Makefile
index a53f3a8..4a022cd 100644
--- a/Makefile
+++ b/Makefile
@@ -1581,6 +1581,7 @@ template_dir_SQ = $(subst ','\'',$(template_dir))
htmldir_relative_SQ = $(subst ','\'',$(htmldir_relative))
prefix_SQ = $(subst ','\'',$(prefix))
gitwebdir_SQ = $(subst ','\'',$(gitwebdir))
+sharedir_SQ = $(subst ','\'',$(sharedir))
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
@@ -2334,7 +2335,6 @@ endif
mergetools_instdir_SQ = $(subst ','\'',$(mergetools_instdir))
install_bindir_programs := $(patsubst %,%$X,$(BINDIR_PROGRAMS_NEED_X))
$(BINDIR_PROGRAMS_NO_X)
-
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
@@ -2344,6 +2344,9 @@ install: all
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
$(INSTALL) -m 644 mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
+ $(INSTALL) -D -m 644 shared/git-completion.bash
'$(DESTDIR_SQ)$(sharedir_SQ)'/bash-completion/completions/git
+ $(INSTALL) -D -m 644 shared/git-prompt.sh
'$(DESTDIR_SQ)$(sharedir_SQ)'/git-core/git-prompt.sh
+ $(INSTALL) -D -m 644 shared/git-completion.zsh
'$(DESTDIR_SQ)$(sharedir_SQ)'/zsh/site-functions/_git
ifndef NO_GETTEXT
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
(cd po/build/locale $(TAR) cf - .) | \
diff --git a/contrib/completion/git-completion.bash b/shared/git-completion.bash
similarity index 100%
rename from contrib/completion/git-completion.bash
rename to shared/git-completion.bash
diff --git a/contrib/completion/git-completion.zsh b/shared/git-completion.zsh
similarity index 100%
rename from contrib/completion/git-completion.zsh
rename to shared/git-completion.zsh
diff --git a/contrib/completion/git-prompt.sh b/shared/git-prompt.sh
similarity index 100%
rename from contrib/completion/git-prompt.sh
rename to shared/git-prompt.sh
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 2d4beb5..d8674e4 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -32,7 +32,7 @@ complete ()
GIT_TESTING_COMMAND_COMPLETION='add checkout check-attr filter-branch ls-files'
-. $GIT_BUILD_DIR/contrib/completion/git-completion.bash
+. $GIT_BUILD_DIR/shared/git-completion.bash
# We don't need this function to actually join words or do anything special.
# Also, it's cleaner to avoid touching bash's internal completion variables.
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 59f875e..272e5b3 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -7,7 +7,7 @@ test_description='test git-specific bash prompt functions'
. ./lib-bash.sh
-. $GIT_BUILD_DIR/contrib/completion/git-prompt.sh
+. $GIT_BUILD_DIR/shared/git-prompt.sh
actual=$TRASH_DIRECTORY/actual
c_red='\\[\\e[31m\\]'
--
1.9.2+fc1.20.g204a630
--
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
Re: Watchman support for git
On Sat, May 3, 2014 at 6:14 AM, dtur...@twopensource.com wrote:
The index format change might be less important with the split index;
I haven't investigated that since at the time I wrote these patches,
it didn't exist.
This is the worst case scenario of git status on webkit.git (182k
files, path name 74 byte long on average), hot cache, no SSD
366.379ms gitmodules_config:199 if (read_cache() 0) die(index file
0.004ms cmd_status:1294 read_cache_preload(s.pathspec);
488.433ms cmd_status:1295 refresh_index(the_index, REFRESH_QUIE
456.495ms cmd_status:1299 update_index_if_able(the_index, inde
13.088ms wt_status_collect:616 wt_status_collect_changes_worktree(s)
706.926ms wt_status_collect:621 wt_status_collect_changes_index(s)
100.495ms lazy_init_name_hash:136 { int nr; if (istate-name_hash_initia
921.185ms wt_status_collect:622 wt_status_collect_untracked(s)
real0m2.969s
user0m1.943s
sys 0m1.021s
Index v4 and split index (and the following read-cache daemon,
hopefully) should help reduce numbers of the 1st and 4th lines, I
expect to less than 50ms each line. lazy_init_name_hash could be taken
away with read-cache daemon also.
core.preloadindex can cut the total number of 2nd and 3rd lines by
half. Watchman should help in these two lines, but it should do better
than core.preloadindex.
wt_status_collect_changes_index() depends on how damaged cache-tree is
(in this case, totally scraped). watchman does not help this either.
We need to try to heal cache-tree as much as possible to reduce the
number.
The last line could be a competition between watchman and my coming
untracked cache series. I expect to cut the number in that line at
least in half without external dependency.
Patch 2/3 did not seem to make it to the list by the way.. initial
reaction is storing the list of all paths seems too much, but I'll
need to play with it a bit to understand it.
--
Duy
--
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
Re: Pull is Mostly Evil
Jeff King p...@peff.net writes: On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote: Junio C Hamano wrote: If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push does not fast-forward. In addition to barf when it's not a fast-forward, such command can switch the parents, so it appears 'maint' was merged to 'origin/maint'. Many people have complained about this order. I realize this has veered off into talking about an update command, and not necessarily pull, but since there a lot of proposals floating around, I wanted to make one point: if we are going to do such a switch, let's please make it something the user explicitly turns on. A safety catch defaulting to a factory position of off is not going to stop inexperienced people from shooting themselves in the foot. -- David Kastrup -- 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
RE: Watchman support for git
On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote: dturner@ wrote: Test repository 1: Linux Linux is about 45k files in 3k directories. The average length of a filename is about 32 bytes. Git status timing: no watchman: 125ms watchman: 90ms That's very interesting. Do you get similar improvements when doing something similar in Merurial (watchman vs . no watchman). I have not tried it. My understanding is that this is why Facebook wrote Watchman and added support for it to Mercurial, so I would assume that the improvements are at least this good. -- 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
RE: Watchman support for git
David Turner wrote: On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote: dturner@ wrote: Test repository 1: Linux Linux is about 45k files in 3k directories. The average length of a filename is about 32 bytes. Git status timing: no watchman: 125ms watchman: 90ms That's very interesting. Do you get similar improvements when doing something similar in Merurial (watchman vs . no watchman). I have not tried it. My understanding is that this is why Facebook wrote Watchman and added support for it to Mercurial, so I would assume that the improvements are at least this good. Yeah, my bet is that they are actually much better (because Mercurial can't be so optimized as Git). I'm interested in this number because if watchman in Git is improving it by 30%, but in Mercurial it's improving it by 100% (made up number), therefore it makes sens that you might want it more if you are using hg, but not so much if you are using git. Also, if similar repositories with Mercurial+watchman are actually faster than Git+watchman, that means that there's room for improvement in your implementation. This is not a big issue at this point of the process, just something nice to know. -- 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
Re: Watchman support for git
On Sat, 2014-05-03 at 07:52 +0700, Duy Nguyen wrote:
On Sat, May 3, 2014 at 6:14 AM, dtur...@twopensource.com wrote:
The index format change might be less important with the split index;
I haven't investigated that since at the time I wrote these patches,
it didn't exist.
This is the worst case scenario of git status on webkit.git (182k
files, path name 74 byte long on average), hot cache, no SSD
366.379ms gitmodules_config:199 if (read_cache() 0) die(index file
0.004ms cmd_status:1294 read_cache_preload(s.pathspec);
488.433ms cmd_status:1295 refresh_index(the_index, REFRESH_QUIE
456.495ms cmd_status:1299 update_index_if_able(the_index, inde
13.088ms wt_status_collect:616 wt_status_collect_changes_worktree(s)
706.926ms wt_status_collect:621 wt_status_collect_changes_index(s)
100.495ms lazy_init_name_hash:136 { int nr; if (istate-name_hash_initia
921.185ms wt_status_collect:622 wt_status_collect_untracked(s)
real0m2.969s
user0m1.943s
sys 0m1.021s
For me, those times are:
0m0.581s (no watchman, index v4)
0m0.465s (watchman, index v4)
0m0.445s (watchman, index v5)
That's not huge win on its own, but (a) it's better than nothing and (b)
it lays the groundwork for other improvements.
A fair amount (~12%) of the time seems to be spent in zlib; this varies
based on how the data is packed IIRC.
Index v4 and split index (and the following read-cache daemon,
hopefully)
Looking at some of the archives for read-cache daemon, it seems to be
somewhat similar to watchman, right? But I only saw inotify code; what
about Mac OS? Or am I misunderstanding what it is?
should help reduce numbers of the 1st and 4th lines, I
expect to less than 50ms each line. lazy_init_name_hash could be taken
away with read-cache daemon also.
core.preloadindex can cut the total number of 2nd and 3rd lines by
half. Watchman should help in these two lines, but it should do better
than core.preloadindex.
wt_status_collect_changes_index() depends on how damaged cache-tree is
(in this case, totally scraped). watchman does not help this either.
We need to try to heal cache-tree as much as possible to reduce the
number.
The last line could be a competition between watchman and my coming
untracked cache series. I expect to cut the number in that line at
least in half without external dependency.
I hadn't seen the untracked cached work (I actually finished these
patches a month or so ago but have been waiting for some internal
reviews before sending them out). Looks interesting. It seems we use a
similar strategy for handling ignores.
Patch 2/3 did not seem to make it to the list by the way..
Thanks for your comments. I just tried again to send patch 2/3. I do
actually see the CC of it in my @twitter.com mailbox, but I don't see it
in the archives on the web. Do you know if there is a reason the
mailing list would reject it? At any rate, the contents may be found
at
https://github.com/dturner-tw/git/commit/cf587d54fc72d82a23267348afa2c4b60f14ce51.diff
initial
reaction is storing the list of all paths seems too much, but I'll
need to play with it a bit to understand it.
I wonder if it would make sense to use the untracked cache as the
storage strategy, but use watchman as the update strategy.
--
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
Re: [PATCH] git-p4: format-patch to diff-tree change breaks binary patches
This is the error message git-apply emits in this case: error: cannot apply binary patch to 'filename' without full index line error: filename: patch does not apply Cheers, Tolga Any feedback is appreciated. Cheers, Tolga -- 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
