Running interpret-trailers automatically on each commit?
I see that interpret-trailers has been added by default in git 2.5.0. However the documentation isn't that great and I can't tell whether it gets run automatically when I do a "git commit". My guess is that it doesn't - that you have to set up a hook to get it to run each commit. As far as I can tell, there is no way to configure global git hooks. Sure, you can set init.templatedir but that only applies for newly-init'ed or cloned repos. So if I have 50 repos on my hard drive I still have to go through every one of them and set up a hook for it. Basically, am I right in thinking that there is *still* no way for me to configure git (on a global, not per-repo basis) to automatically tack a trailer onto every commit message? For the record, I want that trailer to be the current branch name. -- Best regards, Jeremy Morton (Jez) -- 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: Running interpret-trailers automatically on each commit?
Yeah but it's kind of useless to me having it on each commit on a per-repo basis (and even then, only with hooks). -- Best regards, Jeremy Morton (Jez) On 28/08/2015 18:06, Junio C Hamano wrote: Jeremy Morton writes: I see that interpret-trailers has been added by default in git 2.5.0. However the documentation isn't that great and I can't tell whether it gets run automatically when I do a "git commit". My guess is that it doesn't - that you have to set up a hook to get it to run each commit. All correct, except that it happend in 2.2 timeframe. A new experimental feature is shipped, so that people can gain experience with it and come up with the best practice in their hooks, and then laster we may fold the best practice into somewhere deeper in the system. We are still in the early "ship an experimental feature to let people play with it" stage. Thanks. -- 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 -- 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
Autoupdate / autoinit submodules?
Apologies if this has already been discussed, but did any of the proposed patches to allow .gitmodules to be configured for a submodule to be automatically recursive cloned and/or automatically updated on pull make it in yet? My use-case for submodules - which is shared libraries - almost always requires a recursive clone, so having to remember the --recursive param (or to use an alias) is annoying (and I usually forget), and it usually requires pulling the latest master on a "git pull", too. I think both of these things should be able to be automated through git module configuration. -- Best regards, Jeremy Morton (Jez)
Re: [RFC PATCH] clone: add clone.recursesubmodules config option
Did this ever get anywhere? Can we recursively update submodules with
"git pull" in the supermodule now?
--
Best regards,
Jeremy Morton (Jez)
On 04/06/2014 10:30, Chris Packham wrote:
Add a config option that will cause clone to recurse into submodules as
if the --recurse-submodules option had been specified on the command
line. This can be overridden with the --no-recurse-submodules option.
Signed-off-by: Chris Packham
---
On 04/06/14 09:05, Junio C Hamano wrote:
Mara Kim writes:
Apologies if this question has been asked already, but what is the
reasoning behind making git clone not recursive (--recursive) by
default?
The primary reason why submodules are separate repositories is not
to require people to have everything. Some people want recursive,
some others don't, and the world is not always "majority wins" (not
that I am saying that majority will want recursive).
Inertia, aka backward compatibility and not surprising existing
users, plays some role when deciding the default.
Also, going --recursive when the user did not want is a lot more
expensive mistake to fix than not being --recursive when the user
wanted to.
Having said all that, I do not mean to say that I am opposed to
introduce some mechanism to let the users express their preference
between recursive and non-recursive better, so that "git clone"
without an explicit --recursive (or --no-recursive) can work to
their taste. A configuration in $HOME/.gitconfig might be a place
to start, even though that has the downside of assuming that the
given user would want to use the same settings for all his projects,
which may not be the case in practice.
And here's a quick proof of concept. Not sure about the config variable name
and it could probably do with a negative test as well.
builtin/clone.c | 9 +
t/t7407-submodule-foreach.sh | 17 +
2 files changed, 26 insertions(+)
diff --git a/builtin/clone.c b/builtin/clone.c
index b12989d..92aea81 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -734,6 +734,14 @@ static void write_refspec_config(const char*
src_ref_prefix,
strbuf_release(&value);
}
+static int git_clone_config(const char *key, const char *value, void *data)
+{
+ if (!strcmp(key, "clone.recursesubmodules"))
+ option_recursive = git_config_bool(key, value);
+
+ return 0;
+}
+
int cmd_clone(int argc, const char **argv, const char *prefix)
{
int is_bundle = 0, is_local;
@@ -759,6 +767,7 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
junk_pid = getpid();
packet_trace_identity("clone");
+ git_config(git_clone_config, NULL);
argc = parse_options(argc, argv, prefix, builtin_clone_options,
builtin_clone_usage, 0);
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 7ca10b8..fc2c189 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -307,6 +307,23 @@ test_expect_success 'use "update --recursive nested1" to
checkout all submodules
)
'
+test_expect_success 'use "git clone" with clone.recursesubmodules to checkout
all submodules' '
+ git config --local clone.recursesubmodules true&&
+ git clone super clone7&&
+ (
+ cd clone7&&
+ git rev-parse --resolve-git-dir .git&&
+ git rev-parse --resolve-git-dir sub1/.git&&
+ git rev-parse --resolve-git-dir sub2/.git&&
+ git rev-parse --resolve-git-dir sub3/.git&&
+ git rev-parse --resolve-git-dir nested1/.git&&
+ git rev-parse --resolve-git-dir nested1/nested2/.git&&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/.git&&
+ git rev-parse --resolve-git-dir
nested1/nested2/nested3/submodule/.git
+ )&&
+ git config --local --unset clone.recursesubmodules
+'
+
test_expect_success 'command passed to foreach retains notion of stdin' '
(
cd super&&
Reference a submodule branch instead of a commit
At the moment, supermodules must reference a given commit in each of its submodules. If one is in control of a submodule and it changes on a regular basis, this can cause a lot of overhead with "submodule updated" commits in the supermodule. It would be useful of git allows the option of referencing a submodule's branch instead of a given submodule commit. How about adding this functionality? -- Best regards, Jeremy Morton (Jez)
Allow git alias to override existing Git commands
It's recently come to my attention that the "git alias" config functionality ignores all aliases that would override existing Git commands. This seems like a bad idea to me. For example, I wanted to setup "git clone" to automatically act as "git clone --recursive". Sure I could do it in the shell, but it's more of a pain - any tutorial I set up about doing it would have to worry about what shell the user was using - and if you're going to make that argument, why have "git alias" at all? It can all be done from the shell. Obviously I could also use a different alias that wasn't an existing Git command for this behaviour, but that would rather defeat the point: I want "git clone" to have different functionality. If I remembered to use a different Git command, I might as well remember to type "git clone --recursive". Also, if a future Git command were introduced with the same name as my alias, my alias's functionality would suddenly be ignored, giving unexpected behaviour. The reasoning behind this that it's "to avoid confusion and troubles with script usage" seems to be at odds with the general Git mentality that the user is given lots of power, and if they screw it up it's basically just user error. For example, Git doesn't *have* to allow you to rebase. It's a potentially dangerous operation, so why is it allowed? It might "cause confusion and troubles". On the other hand, by disallowing the overriding of existing Git commands through aliases you are preventing a lot of useful functionality that those aliases might be used for. So I think you should either allow Git aliases to override existing Git commands by default, or at least provide a config option that allows the user to say that this should happen. -- Best regards, Jeremy Morton (Jez) -- 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: Allow git alias to override existing Git commands
On 10/11/2015 18:12, Stefan Beller wrote: On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton wrote: It's recently come to my attention that the "git alias" config functionality ignores all aliases that would override existing Git commands. This seems like a bad idea to me. This ensures that the plumbing commands always work as expected. As scripts *should* only use plumbing commands, the scripts should work with high probability despite all the crazy user configuration/aliases. I just disagree with this. If a user chooses to override their Git commands, it's their problem. Why should Git care about this? It should provide the user with the option to do this, and if the user ruins scripts because of their aliases, it is not Git's problem. What you are doing is taking away power from users to use git aliases to their full potential. -- Best regards, Jeremy Morton (Jez) -- 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: Allow git alias to override existing Git commands
On 11/11/2015 04:48, Sitaram Chamarty wrote: A lot of things in Unix do follow that "give you rope to hang yourself" philosophy. I used to (and to *some* extent still do) think like that, but some years of supporting normal users trying to do stuff has taught me it's not always that simple. I can easily see someone blogging some cool way to do something, and a less savvy user uses that in his gitconfig, and gets burned later (possibly much later, enough that he does not easily make the connection!) We're not talking about "normal users" here, that's what Google Chrome is for. We're talking about Git users using the commandline client. They ought to know what they're doing and if they don't, they're screwed anyway because there are quite a few gotchas with Git. -- Best regards, Jeremy Morton (Jez) -- 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: Allow git alias to override existing Git commands
On 11/11/2015 09:51, Sitaram Chamarty wrote: I can only repeat what I said before: it's not all black and white. Reducing the opportunity to make mistakes is useful for everyone, even expetrs. Especially stuff that you may have setup aeons ago and hits you only aeons later when something (supposedly unrelated) somewhere else changes and you didn't remember and you tear your hair out. Not when it reduces useful functionality for experts, it's not. -- Best regards, Jeremy Morton (Jez) -- 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
Strange bug with "git log" - pdftotext?
I'm trying to search my git log history for a particular term - "unobtrusive" - so I run this command: git log -S unobtrusive --oneline When I do this, this is displayed and I'm in an interactive less terminal or something: pdftotext version 4.00 Copyright 1996-2017 Glyph & Cog, LLC Usage: pdftotext [options] [] -f : first page to convert -l : last page to convert -layout : maintain original physical layout -simple : simple one-column page layout -table : similar to -layout, but optimized for tables -lineprinter : use strict fixed-pitch/height layout -raw : keep strings in content stream order -fixed : assume fixed-pitch (or tabular) text -linespacing : fixed line spacing for LinePrinter mode -clip: separate clipped text -nodiag : discard diagonal text -enc : output text encoding name -eol : output end-of-line convention (unix, dos, or mac) -nopgbrk : don't insert page breaks between pages -bom : insert a Unicode BOM at the start of the text file -opw : owner password (for encrypted files) -upw : user password (for encrypted files) -q : don't print any messages or errors -cfg : configuration file to use in place of .xpdfrc -v : print copyright and version info : When I hit the down arrow, it scrolls down, repeating this output infinitely until I hit 'q'. What is going on here?? -- Best regards, Jeremy Morton (Jez)
Re: Strange bug with "git log" - pdftotext?
I discovered it was an issue with the version of Git for Windows I was using. Upgraded to the latest version and it works now. -- Best regards, Jeremy Morton (Jez) On 30/07/2018 16:37, Jeff King wrote: On Mon, Jul 30, 2018 at 01:49:46PM +0100, Jeremy Morton wrote: I'm trying to search my git log history for a particular term - "unobtrusive" - so I run this command: git log -S unobtrusive --oneline When I do this, this is displayed and I'm in an interactive less terminal or something: pdftotext version 4.00 [...] That's definitely weird. My guess is that the repository has some .gitattributes set up to diff pdf files in a particular way, and you have some matching config that tries to call pdftotext. What does: git config --list | grep ^diff say? I'd expect to see an external or textconv option there running pdftotext. Another option is that your pager is somehow set up to call pdftotext, but that seems much more nonsensical to use the tool there (but try "git var GIT_PAGER" and "git config pager.log" to check). -Peff
Re: [RFC PATCH] clone: add clone.recursesubmodules config option
Did this ever get anywhere? If not why not? It would be very useful to me to be able to clone recursively by default, especially considering you can't use 'alias' to override the existing 'clone' command. -- Best regards, Jeremy Morton (Jez) On 06/06/2014 06:26, Heiko Voigt wrote: On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote: Jens Lehmann writes: We had two settings in mind,... So what if clone would just do an "git submodule init" for now when "submodule.autoinit" is set but "submodule.autoupdate" isn't [?] ... and a single "submodule.auto" setting would be what users really want? I do not offhand think of a sensible scenario where you want to init a submodule once but do not want to update it when the superproject changes. Even if the user uses the mode to detach the submodule HEAD, i.e. the branches in submodules do not matter and the whole tree is described by the superproject's commit and gitlinks recorded in it, the user would want the new objects necessary for the updated superproject, which means a submodule that is init'ed (whether it is via "git submodule init" or the submodule.autoinit variable) must be updated. So I am not sure why a user wants to disable autoupdate in the first place. For the same reason, setting submodule.*.update to none would not make much sense, either. Perhaps I am missing something. Unless the user is very conservative and suspects that these recursive behaviour we are going to bolt on to various commands could be buggy and untrustworthy, in which case the user might want to manually run "git submodule update", or even run "git fetch" after going there while bypassing the whole "git submodule". But I do not think that is healthy in the longer run. I think autoupdate is mainly there for the transition phase. Since submodule can e.g. contain a lot of files a checkout would take much longer. Similar to when Jens implemented the recursive diff, many people were annoyed by the new files showing up and some with the impact on performance (thats why we have the --ignore-submodules option). In case of very big submodules and people already ignore their diff it might even be necessary that the update is only done manually. E.g. for a big media repository. Cheers Heiko -- 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
Recording the current branch on each commit?
Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says "Added basic options dialog", it might be useful to see that the branch name is "pacman-minigame" indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? -- Best regards, Jeremy Morton (Jez) -- 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: Recording the current branch on each commit?
On 27/04/2014 09:51, Robin Rosenberg wrote: Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says "Added basic options dialog", it might be useful to see that the branch name is "pacman-minigame" indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? Branch names are usually poorly named, so often you don't lose much. One way Speak for yourself - I give my branches useful names. :-) I definitely feel that I am often losing useful contextual information by throwing away the branch name. some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where a branch was merged to try and figure out which branch name a commit pertained to, not to mention the fact that the commit could've been moved since. Nothing short of tagging the commit with the branch name when the commit is made will definitely record the branch name at the time of committing. A very popular way of tracking context is to add some id, such as a bugzilla issue number, to the header or footer of the commit message. Often a branch contains many issues, but the branch itself isn't very interesting. Tools like gitblit, gitweb, gerrit etc can easily be configured to link to the issue using a regular expression. Yes, and I have done this kind of thing in the past. However you really don't want to put the bug# on every single commit pertaining to that bug; you have to go to the effort of looking the bug# up every time, you'll sometimes forget, and besides it takes up space that could be used for a commit message. As short commit messages are valued in Git, it's particularly bad to waste space this way. Much better would be to include the bug# as part of the branch name, and then if you record the branch name upon checkin you always get a reference to the bug#. Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. -- Best regards, Jeremy Morton (Jez) -- 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: Recording the current branch on each commit?
On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it would
be useful if, along with the Author and Date, git recorded the name of the
current branch on each commit.
This has been discussed multiple times in the past. One example here:
http://thread.gmane.org/gmane.comp.version-control.git/229422
I believe the current conclusion (if any) is that encoding such
information as a _structural_ part of the commit object is not useful.
See the old thread(s) for the actual pro/con arguments.
As far as I can tell from that discussion, the general opposition to
encoding the branch name as a structural part of the commit object is
that, for some people's workflows, it would be unhelpful and/or
misleading. Well fair enough then - why don't we make it a setting that
is off by default, and can easily be switched on? That way the people
for whom tagging the branch name would be useful have a very easy way to
switch it on. I know that for the workflows I personally have used in
the past, such tagging would be very useful. Quite often I have been
looking through the Git log and wondered what feature a commit was "part
of", because I have feature branches. Just knowing that branch name
would be really useful, but the branch has since been deleted... and in
the case of a ff-merge (which I thought was recommended in Git if
possible), the branch name is completely gone.
That said, you are of course free to add this information to your own
commit messages, by appending something like "Made-on-branch: frotz".
In a company setting, you can even create a commit message template or
(prepare-)commit-msg hook to have this line created automatically for
you and your co-workers. You could even append such information
retroactively to existing commits with "git notes". There is also the
current interpret-trailers effort by Christian Couder [1] that should
be useful in creating and managing such lines.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/245874
Well I guess that's another way of doing it. So, why aren't Author and
Date trailers? They don't seem any more fundamental to me than branch
name. I mean the only checkin information you really *need* is the
checksum, and commit's parents. The Author and Date are just extra
pieces of information you might find useful sometimes, right? A bit
like some people might find branch checkin name useful sometimes...?
The branch name can provide useful
contextual information. For instance, let's say I'm developing a suite of
games. If the commit message says "Added basic options dialog", it might be
useful to see that the branch name is "pacman-minigame" indicating that the
commit pertains to the options dialog in the Pacman minigame.
In that partcular case, ISTM that the context ("pacman-minigame")
would actually be better preserved elsewhere. E.g. the commits touch
files in a particular "minigames/pacman" subdir, or you prefix the
context in the commit message ("pacman-minigame: Added basic options
dialog"). Also, such a "topic" branch is often tied to a specific
Again, this is a pain because you have to remember to manually tag every
commit message with "pacman-minigame", and it takes up precious space in
the (already short) commit message.
issue in some bug/issue tracker, and it would in any case be natural
to mention the bug/issue ID in the commit message, at which point the
tracker can provide more context and discussion.
I think it would only be natural to mention the bug# in the final commit
that actually fixes the bug or implements the feature, not the checkins
leading up to that. And, it's still not *guaranteed* that the coder
will remember to put the bug# in even that commit message.
Basically,
I'm saying that well-named branches can and do carry useful contextual
information that oughtn't to be thrown away. Currently, when you delete
that branch, you lose the branch name altogether.
Some would argue that branches are not always well-named... But
But when they are, why should that info be thrown away? When they're
not well-named, they can be ignored (or the branch name recording
feature can be turned off!)
anyway, if the branch ends up getting merged to the mainline, the
merge commit defaults to a message like "Merge branch
'pacman-minigame'".
Only if it's a non-ff merge, which results in less tidy commit trees,
and hence is often recommended against. Whatsmore, tracking down which
branch a commit pertains to is still rather difficult using this
approach. You can go back through the history and find "Merge branc
Re: Recording the current branch on each commit?
On 27/04/2014 20:33, Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton wrote:
On 27/04/2014 10:09, Johan Herland wrote:
As far as I can tell from that discussion, the general opposition to
encoding the branch name as a structural part of the commit object is that,
for some people's workflows, it would be unhelpful and/or misleading. Well
fair enough then - why don't we make it a setting that is off by default,
and can easily be switched on? That way the people for whom tagging the
branch name would be useful have a very easy way to switch it on.
Therefore, the most pragmatic and constructive thing to do at this
point, is IMHO to work within the confines of the existing commit
object structure. I actually believe using commit message trailers
like "Made-on-branch: frotz" in addition to some helpful
infrastructure (hooks, templates, git-interpret-trailers, etc.) should
get you pretty much exactly what you want. And if this feature turns
out to be extremely useful for a lot of users, we can certainly
consider changing the commit object format in the future.
OK, fair enough. So I guess what I'd like to see, then, is good
built-in functionality in Git for these commit message trailers, so that
they are very easy to turn on. I'd like to be able to tell
co-developers to add a one-liner to their git config file rather than
some post-commit script.
I know
that for the workflows I personally have used in the past, such tagging
would be very useful. Quite often I have been looking through the Git log
and wondered what feature a commit was "part of", because I have feature
branches. Just knowing that branch name would be really useful, but the
branch has since been deleted... and in the case of a ff-merge (which I
thought was recommended in Git if possible), the branch name is completely
gone.
True. The branch name is - for better or worse - simply not considered
very important by Git, and a Git commit is simply not considered (by
Git at least) to "be part of" or otherwise "belong to" any branch.
Please understand that I know this full well. :-) I'm saying that the
'ephemeral' pointers' names are, in themselves, useful - if, like me,
you give them meaningful names. What I'm proposing is pretty much an
automatic tagging (somehow...) of each commit with the current branch
name (if one is available); information that carries roughly the same
weight as the commit message. It could be crap, but equally it could be
very useful, in some workflows. I think most of us can agree on that.
seems to only have come up a few times on the mailing list. This is
But it has come up more than once, which would seem to indicate that I'm
not the only one with this request. ;-)
IINM, Mercurial does this differently, so that may be a better fit for
"If I'm Not Mistaken" - I had to look that one up.
the workflows where keeping track of branch names is very important.
Nah, I had a look at Mercurial and I think I prefer Git - this branch
name thing is just my one bugbear. I definitely prefer Git's concept of
a staging area rather than just committing all changes. To do that in
Mercurial you have to use mq and all the different (IMHO unintuative)
commands that entails, and if you accidentally "mq commit" then you
screw everything up. :-) Mercurial also discourages history rewriting
(ie. cleaning up of messy commits), which Git doesn't. I prefer Git's
approach here too.
Yeah, sure. Author and Date (and Committer, for that matter) is just
metadata, and the current branch name is simply just another kind of
metadata. All of them are more-or-less free-form text fields, and off
the top of my head, I can't really say that if we were to design Git
from scratch today, they wouldn't all become optional trailers (or
headers, or what-have-you).
However, we're not designing Git from scratch, and we have to work
with what is already there...
Fair point.
The branch name can provide useful
contextual information. For instance, let's say I'm developing a suite
of
games. If the commit message says "Added basic options dialog", it might
be
useful to see that the branch name is "pacman-minigame" indicating that
the
commit pertains to the options dialog in the Pacman minigame.
In that partcular case, ISTM that the context ("pacman-minigame")
would actually be better preserved elsewhere. E.g. the commits touch
files in a particular "minigames/pacman" subdir, or you prefix the
context in the commit message ("pacman-minigame: Added basic options
dialog"). Also, such a "topic" branch is often tied to a specific
Again, this is a pain because you have to remember to manually tag every
commit message with "pacman-minigame", and it takes up precious space in t
Re: Recording the current branch on each commit?
On 27/04/2014 22:40, James Denholm wrote: Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. In which case, refer to whatever system you use. If you aren't using a ticketing system, have the line "Relates-to: Water cooler conversation with Bob on July 28th" or whatever the patches relate to. (Arguably, though, the better solution is to use a ticketing system, or anything that allows discussion to be easily referenced.) Well, as I said elsewhere in this discussion, Git should provide that functionality built-in, IMHO. It would be good to be able to set a one-liner in my .gitconfig to tag each commit with a "branch checked into" trailer. -- Best regards, Jeremy Morton (Jez) -- 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: Recording the current branch on each commit?
On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where a branch was merged to try and figure out which branch name a commit pertained to, not to mention the fact that the commit could've been moved since. Nothing short of tagging the commit with the branch name when the commit is made will definitely record the branch name at the time of committing. But why do you need that information? As I said before, I usually consider my branch names useful information worth keeping around - I'm not sure why you don't. I might include a bug# in the branch name so I don't have to keep typing it in every commit message, or I might just have a handy short description of what part of the application this branch is modifying (like my "pacman-minigame" example). -- Best regards, Jeremy Morton (Jez) -- 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: Recording the current branch on each commit?
On 28/04/2014 03:30, Sitaram Chamarty wrote: On 04/28/2014 01:03 AM, Johan Herland wrote: Yeah, sure. Author and Date (and Committer, for that matter) is just metadata, and the current branch name is simply just another kind of metadata. All of them are more-or-less free-form text fields, and off no they're not. In strictly controlled environments they form part of the audit record for the source code. Yes they can be faked (explicitly), but -- again in strictly controlled environments -- that can be limited to "before it was first pushed". Why these specific headers as part of the audit record, though? Aren't you just arbitrarily defining them as part of the audit record? -- Best regards, Jeremy Morton (Jez) -- 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: Recording the current branch on each commit?
On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat>.git/hooks/commit-msg< "\$1.new" mv "\$1.new" "\$1" EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer "git-branch: \$(git name-rev --name-only HEAD)" "\$1"> "\$1.new" It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv "\$1.new" "\$1"' command. Best, Christian. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. -- Best regards, Jeremy Morton (Jez) -- 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: Recording the current branch on each commit?
On 28/04/2014 10:02, David Kastrup wrote: Jeremy Morton writes: On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. And I don't _want_ that branch name to be recorded. The whole point of a distributed version control system is that it's nobody else's business how I organize my work before submitting it. Well it would be optional, so obviously you wouldn't be forced to share the branch name. It's not like we're trying to "pry in" to your private development. It's a way of choosing to share what you may consider to be useful contextual information about the commit. I don't want to have people tell me when submitting patches "but can't you give this a better branch name?" and then have to use git filter-branch or whatever else to get the branch name removed. As I said before, I usually consider my branch names useful information worth keeping around - I'm not sure why you don't. It is _totally_ useless information in a distributed development model. Why would or should anybody be concerned what private branches some submitter has developed his patches in? Why should anybody be concerned about what commit message some submitter has typed in for his commit? They could just read the source code to see what has changed, right? Because the commit message is a way for the submitter to try and make it easier for the people looking at the commit to understand what the commit is doing. In the same way, a meaningful branch name may also make it easier for people looking at the commit to understand what it is doing, or what part of the application it is affecting, or what group of commits it is a part of. -- Best regards, Jeremy Morton (Jez) -- 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: Recording the current branch on each commit?
On 28/04/2014 10:09, Johan Herland wrote: On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton wrote: On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat>.git/hooks/commit-msg< "\$1.new" mv "\$1.new" "\$1" EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer "git-branch: \$(git name-rev --name-only HEAD)" "\$1"> "\$1.new" It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv "\$1.new" "\$1"' command. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. It's a hack, but it works surprisingly well in practice (assuming that you and your co-workers all agree that this is an acceptable approach): 1. Write the hook script and add it to your project (in a git-hooks subdir or something) 2. Add a post-checkout hook to install the first hook and the post-checkout hook itself into the user's .git/hooks/ dir. 3. Tell your co-workers to run the post-checkout hook script manually the first time. After that, the script should take care of updating itself and any hooks that you add to the project. ...Johan I don't understand why the co-workers need to run the post-checkout hook script manually the first time? -- Best regards, Jeremy Morton (Jez) -- 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: Recording the current branch on each commit?
On 28/04/2014 10:01, Felipe Contreras wrote: Jeremy Morton wrote: On 27/04/2014 20:33, Johan Herland wrote: The problem is not really "less tidy commit trees" - by which I gather you mean history graphs that are non-linear. IMHO, the history graph should reflect parallel/branched development when that is useful. Blindly rebasing everything into a single line is IMHO just as bad as doing all your work directly on master and blindly running "git pull" between each of your own commits (which results in a lot of useless merges). The merge commits themselves are not the problem. Merge commits are a tool, and when used properly (to introduce topics to the master branch like described above) they are a good tool. When abused (like blindly running "git pull" and accepting useless "merge bubbles") they create more problems than they solve. Sounds like the default behaviour of "git pull" might not be ideal if it easily causes these problems. It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we have the patches to fix it, but it's not going to change. The Git project doesn't welcome change. Well, you sure don't seem to. Why are there so many "no-can-do" people on this list? :-) -- Best regards, Jeremy Morton (Jez) -- 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: Recording the current branch on each commit?
On 28/04/2014 10:17, Felipe Contreras wrote: I don't seem to what? I'm the one arguing for change, and I sent the patches to fix this default behavior. Well maybe you should work on phrasing things better - you come across as quite negative. -- Best regards, Jeremy Morton (Jez) -- 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 v10 11/12] Documentation: add documentation for 'git interpret-trailers'
On 28/04/2014 17:37, Junio C Hamano wrote: Christian Couder writes: From: Junio C Hamano Christian Couder writes: ... + trailer. After some alphanumeric characters, it can contain + some non alphanumeric characters like ':', '=' or '#' that will + be used instead of ':' to separate the token from the value in + the trailer, though the default ':' is more standard. I assume that this is for things like bug #538 and the configuration would say something like: [trailer "bug"] key = "bug #" For completeness (of this example), the bog-standard s-o-b would look like Signed-off-by: Christian Couder and the configuration for it that spell the redundant "key" would be: [trailer "Signed-off-by"] key = "Signed-off-by: " Yeah, but you can use the following instead: [trailer "s-o-b"] key = "Signed-off-by: " One thing I'm not quite understanding is where the "Christian Couder" bit comes from. So you've defined the trailer token and key, but interpret-trailers then needs to get the value it will give for the key from somewhere. Does it have to just be hardcoded in? We probably want some way to get various variables like current branch name, current git version, etc. So in the case of always adding a trailer for the branch that the commit was checked in to at the time (Developed-on, Made-on-branch, Author-branch, etc. [I think my favourite is Made-on-branch]), you'd want something like: [trailer "m-o-b"] key = "Made-on-branch: " value = "$currentBranch" ... resulting in the trailer (for example): Made-on-branch: pacman-minigame Also, if there were no current branch name because you're committing in a detached head state, it would be nice if you could have some logic to determine that, and instead write the trailer as: Made-on-branch: (detached HEAD: AB12CD34) ... or whatever. And also how about some logic to be able to say that if you're committing to the "master" branch, the trailer doesn't get inserted at all? -- Best regards, Jeremy Morton (Jez) -- 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 v10 11/12] Documentation: add documentation for 'git interpret-trailers'
On 29/04/2014 12:47, Christian Couder wrote: Also, if there were no current branch name because you're committing in a detached head state, it would be nice if you could have some logic to determine that, and instead write the trailer as: Made-on-branch: (detached HEAD: AB12CD34) You may need to write a small script for that. Then you just need the "trailer.m-o-b.command" config value to point to your script. ... or whatever. And also how about some logic to be able to say that if you're committing to the "master" branch, the trailer doesn't get inserted at all? You can script that too. But it would be nicer if the logic were built-in, then you wouldn't have to share some script with your work colleagues. :-) -- Best regards, Jeremy Morton (Jez) -- 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 v10 11/12] Documentation: add documentation for 'git interpret-trailers'
On 29/04/2014 12:47, Christian Couder wrote: Also, if there were no current branch name because you're committing in a detached head state, it would be nice if you could have some logic to determine that, and instead write the trailer as: Made-on-branch: (detached HEAD: AB12CD34) You may need to write a small script for that. Then you just need the "trailer.m-o-b.command" config value to point to your script. ... or whatever. And also how about some logic to be able to say that if you're committing to the "master" branch, the trailer doesn't get inserted at all? You can script that too. But it would be nicer if the logic were built-in, then you wouldn't have to share some script with your work colleagues. :-) -- Best regards, Jeremy Morton (Jez) -- 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
Fixing the p4merge launch shell script
Hi,
I've noticed that the p4merge shell script could do with some
improvement when it comes to merging. Because p4merge throws up an
error when one of the files it's given to diff is "/dev/null", git needs
to create a temporary empty file and pass that to p4merge when diffing a
file that has been created/deleted (eg. create file, git add ., git diff
--cached).
At the moment, the hack I'm using, which works, is to create a
c:/blank.txt file which is an empty file, and modify
"libexec/git-core/mergetools/p4merge" to start with this:
diff_cmd () {
if [ ! -f "$LOCAL" ]
then
LOCAL="C:/blank.txt"
fi
if [ ! -f "$REMOTE" ]
then
REMOTE="C:/blank.txt"
fi
"$merge_tool_path" "$LOCAL" "$REMOTE"
}
Obviously, this isn't good enough because c:/blank.txt probably won't
exist on the system. It would be nice for the temporary blank file to
have the same extension as the one that's been added, so we could diff
(say) c:/users/jez/Temp/abc123_newFile.foo
c:/development/bar/newfile.foo. However, I can't see a way to do this
purely from within the shell script (even `mktemp` doesn't exist on all
systems so that isn't good enough). I believe git needs to create this
temporary blank file itself, much like it creates a temporary file for
the previous version of a file that's been modified when it's being
diff'd. It then needs to expose the location of this temporary file as
a variable; say $LOCALBLANK. So, we would be able to modify the shell
script to this:
diff_cmd () {
if [ ! -f "$LOCAL" ]
then
LOCAL=$LOCALBLANK
fi
if [ ! -f "$REMOTE" ]
then
REMOTE=$REMOTEBLANK
fi
"$merge_tool_path" "$LOCAL" "$REMOTE"
}
Thoughts? Is there an easier way to do this?
--
Best regards,
Jeremy Morton (Jez)
--
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: Fixing the p4merge launch shell script
Junio C Hamano pobox.com> writes: > > Jeremy Morton game-point.net> writes: > > > I've noticed that the p4merge shell script could do with some > > improvement when it comes to merging. Because p4merge throws up an > > error when one of the files it's given to diff is "/dev/null", git > > needs to create a temporary empty file and pass that to p4merge when > > diffing a file that has been created/deleted (eg. create file, git add > > ., git diff --cached). > > ... > > Thoughts? Is there an easier way to do this? > > Which version of git? Perhaps you do not have ec245ba (mergetool: > Provide an empty file when needed, 2012-01-19) yet? > That patch fixes the mergetool part, but the part I was referring to was the difftool part, which still has this problem. Best regards, Jeremy Morton (Jez) -- 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
Bizarre problem cloning repo from Codeplex
I'm trying to clone the following repository from Codeplex: https://git01.codeplex.com/entityframework.git git downloads all the objects, creates the directory "entityframework", then displays "error: RPC failed; result=56, HTTP code = 200" and immediately deletes the directory. I can clone other HTTPS repos with this git installation, for example from Bitbucket and Github. It's git 1.7.10.4 on Debian. I can also clone this codeplex repo OK on my windows git installation (1.7.11.msysgit.1). I'm totally perplexed; anyone have any idea what is going wrong with the Debian git installation here? -- Best regards, Jeremy Morton (Jez) -- 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] mergetools/p4merge: Handle "/dev/null"
Sorry to be replying to this so late; I hadn't noticed the post until now!
I've tried putting that code in my p4merge script and yes it does indeed
work fine. However, it puts a temporary file in the working directory
which I'm not sure is a good idea? If we look at this patch which
actually solved pretty much the same problem, but when merging and,
during a merge conflict, a file was created in both branches:
https://github.com/git/git/commit/ec245ba
... it is creating a temp file in a proper temp dir, rather than in the
working dir. I think that would be the proper solution here. However,
I really want to get this fixed so I'd be happy for this band-aid fix of
the p4merge script to be checked in until we could get a patch more like
the aforementioned one, at a later date, to create empty files in a
proper temp dir and pass them as $LOCAL and $REMOTE. :-)
--
Best regards,
Jeremy Morton (Jez)
On 11/10/2012 04:22, David Aguilar wrote:
p4merge does not properly handle the case where "/dev/null"
is passed as a filename.
Workaround it by creating a temporary file for this purpose.
Reported-by: Jeremy Morton
Signed-off-by: David Aguilar
---
Jeremy, can you test this?
mergetools/p4merge | 25 +
1 file changed, 25 insertions(+)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 1a45c1b..295361a 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -1,5 +1,30 @@
diff_cmd () {
+ # p4merge does not like /dev/null
+ rm_local=
+ rm_remote=
+ if test "/dev/null" = "$LOCAL"
+ then
+ LOCAL="./p4merge-dev-null.LOCAL.$$"
+ >"$LOCAL"
+ rm_local=true
+ fi
+ if test "/dev/null" = "$REMOTE"
+ then
+ REMOTE="./p4merge-dev-null.REMOTE.$$"
+ >"$REMOTE"
+ rm_remote=true
+ fi
+
"$merge_tool_path" "$LOCAL" "$REMOTE"
+
+ if test -n "$rm_local"
+ then
+ rm -f "$LOCAL"
+ fi
+ if test -n "$rm_remote"
+ then
+ rm -f "$REMOTE"
+ fi
}
merge_cmd () {
--
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
