It is a bit embarrassing but it turns out that all cross links in the HTML version of manual pages in Git 1.7.11 were missing, so a brown-paper-bag maintenance release 1.7.11.1 is out.
Thursday, June 21, 2012
Sunday, June 3, 2012
Git 1.7.10.4 and Git 1.7.11-rc1
All the fixes to 1.7.10.x maintenance track that have been cooking on the master branch have also been merged and 1.7.10.4 release has been pushed out. Hopefully this will be the last release from the 1.7.10.x track. For the list of changes in this release, please see its release notes.
Finally 1.7.11-rc1 has been tagged. We originally wanted to keep this cycle on the shorter side of the 8-10 week release cycle, so that the end of the next cycle would coincide better with the end of GSoC, but it appears that it is looking like somewhat a lost cause. In any case, this marks the end of feature tweaks and bugfixes in this cycle and the focus shifts to finding and fixing regressions introduced since 1.7.10.
Please download, build and test the release candidate so that users do not have to suffer from regressions in the final 1.7.11 release.
Finally 1.7.11-rc1 has been tagged. We originally wanted to keep this cycle on the shorter side of the 8-10 week release cycle, so that the end of the next cycle would coincide better with the end of GSoC, but it appears that it is looking like somewhat a lost cause. In any case, this marks the end of feature tweaks and bugfixes in this cycle and the focus shifts to finding and fixing regressions introduced since 1.7.10.
Please download, build and test the release candidate so that users do not have to suffer from regressions in the final 1.7.11 release.
Friday, May 25, 2012
Git 1.7.10.3 and Git 1.7.11-rc0
Two releases for a day.
The third maintenance release for 1.7.10.X series fixes a handful of regressions in previous 1.7.10.X releases.
On the master front, 1.7.11-rc0 is out. Treat it as a preview of the real release candidate for the next big release—there still are several topics cooking in the next branch to shake out possible new bugs to make sure we can have a solid 1.7.11 release.
The most notable, from the long-term point of view, is the introduction of the simple push mode (credit goes to Matthieu Moy), which would hopefully prove to be a good default for new users until they configure the push.default to suit the requirement of their project. With this, running git push or git push origin without saying which branches and/or tags to update what on the remote side from either command line or from the remote.$name.push configuration will only push the current branch to the branch of the same name on the other side, but only if the current branch is configured to use the branch on the other side as its upstream.
Have fun.
The third maintenance release for 1.7.10.X series fixes a handful of regressions in previous 1.7.10.X releases.
On the master front, 1.7.11-rc0 is out. Treat it as a preview of the real release candidate for the next big release—there still are several topics cooking in the next branch to shake out possible new bugs to make sure we can have a solid 1.7.11 release.
The most notable, from the long-term point of view, is the introduction of the simple push mode (credit goes to Matthieu Moy), which would hopefully prove to be a good default for new users until they configure the push.default to suit the requirement of their project. With this, running git push or git push origin without saying which branches and/or tags to update what on the remote side from either command line or from the remote.$name.push configuration will only push the current branch to the branch of the same name on the other side, but only if the current branch is configured to use the branch on the other side as its upstream.
Have fun.
Tuesday, May 1, 2012
Git 1.7.10.1
The first maintenance release for 1.7.10.x series is out.
Git v1.7.10.1 Release Notes
===========================
Additions since v1.7.10
-----------------------
Localization message files for Danish and German have been added.
Fixes since v1.7.10
-------------------
* "git add -p" is not designed to deal with unmerged paths but did
not exclude them and tried to apply funny patches only to fail.
* "git blame" started missing quite a few changes from the origin
since we stopped using the diff minimalization by default in v1.7.2
era.
* When PATH contains an unreadable directory, alias expansion code
did not kick in, and failed with an error that said "git-subcmd"
was not found.
* "git clean -d -f" (not "-d -f -f") is supposed to protect nested
working trees of independent git repositories that exist in the
current project working tree from getting removed, but the
protection applied only to such working trees that are at the
top-level of the current project by mistake.
* "git commit --author=$name" did not tell the name that was being
recorded in the resulting commit to hooks, even though it does do
so when the end user overrode the authorship via the
"GIT_AUTHOR_NAME" environment variable.
* When "git commit --template F" errors out because the user did not
touch the message, it claimed that it aborts due to "empty
message", which was utterly wrong.
* The regexp configured with diff.wordregex was incorrectly reused
across files.
* An age-old corner case bug in combine diff (only triggered with -U0
and the hunk at the beginning of the file needs to be shown) has
been fixed.
* Rename detection logic used to match two empty files as renames
during merge-recursive, leading to unnatural mismerges.
* The parser in "fast-import" did not diagnose ":9" style references
that is not followed by required SP/LF as an error.
* When "git fetch" encounters repositories with too many references,
the command line of "fetch-pack" that is run by a helper
e.g. remote-curl, may fail to hold all of them. Now such an
internal invocation can feed the references through the standard
input of "fetch-pack".
* "git fetch" that recurses into submodules on demand did not check
if it needs to go into submodules when non branches (most notably,
tags) are fetched.
* "log -p --graph" used with "--stat" had a few formatting error.
* Running "notes merge --commit" failed to perform correctly when run
from any directory inside $GIT_DIR/. When "notes merge" stops with
conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits
to resolve it.
* The 'push to upstream' implementation was broken in some corner
cases. "git push $there" without refspec, when the current branch
is set to push to a remote different from $there, used to push to
$there using the upstream information to a remote unreleated to
$there.
* Giving "--continue" to a conflicted "rebase -i" session skipped a
commit that only results in changes to submodules.
Also contains minor fixes and documentation updates.
Git v1.7.10.1 Release Notes
===========================
Additions since v1.7.10
-----------------------
Localization message files for Danish and German have been added.
Fixes since v1.7.10
-------------------
* "git add -p" is not designed to deal with unmerged paths but did
not exclude them and tried to apply funny patches only to fail.
* "git blame" started missing quite a few changes from the origin
since we stopped using the diff minimalization by default in v1.7.2
era.
* When PATH contains an unreadable directory, alias expansion code
did not kick in, and failed with an error that said "git-subcmd"
was not found.
* "git clean -d -f" (not "-d -f -f") is supposed to protect nested
working trees of independent git repositories that exist in the
current project working tree from getting removed, but the
protection applied only to such working trees that are at the
top-level of the current project by mistake.
* "git commit --author=$name" did not tell the name that was being
recorded in the resulting commit to hooks, even though it does do
so when the end user overrode the authorship via the
"GIT_AUTHOR_NAME" environment variable.
* When "git commit --template F" errors out because the user did not
touch the message, it claimed that it aborts due to "empty
message", which was utterly wrong.
* The regexp configured with diff.wordregex was incorrectly reused
across files.
* An age-old corner case bug in combine diff (only triggered with -U0
and the hunk at the beginning of the file needs to be shown) has
been fixed.
* Rename detection logic used to match two empty files as renames
during merge-recursive, leading to unnatural mismerges.
* The parser in "fast-import" did not diagnose ":9" style references
that is not followed by required SP/LF as an error.
* When "git fetch" encounters repositories with too many references,
the command line of "fetch-pack" that is run by a helper
e.g. remote-curl, may fail to hold all of them. Now such an
internal invocation can feed the references through the standard
input of "fetch-pack".
* "git fetch" that recurses into submodules on demand did not check
if it needs to go into submodules when non branches (most notably,
tags) are fetched.
* "log -p --graph" used with "--stat" had a few formatting error.
* Running "notes merge --commit" failed to perform correctly when run
from any directory inside $GIT_DIR/. When "notes merge" stops with
conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits
to resolve it.
* The 'push to upstream' implementation was broken in some corner
cases. "git push $there" without refspec, when the current branch
is set to push to a remote different from $there, used to push to
$there using the upstream information to a remote unreleated to
$there.
* Giving "--continue" to a conflicted "rebase -i" session skipped a
commit that only results in changes to submodules.
Also contains minor fixes and documentation updates.
Monday, April 30, 2012
Naming a machine
When I came to Google, I asked my desktop machine to be named "linus". I was asked: "Do you really want your machine named linus?"
But the thing is, the requested name is not after Linus Torvalds. I name my machines using a dictionary. Let me explain how. I name my machines after some theme, and the machine "linus", just like my primary box "alter", is named after the primary activity I was planning to do on it, namely "Git".
The first thing to do is to find a bunch of dictionary words that have G, I and T in this order. We may find these words: afGhanIsTan, linGuIsT, aGlITter,...
Then remove these G, I and T from these dictionary words to obtain: afhansan, linus, alter,...
Finally, pick ones that can be pronounced and preferrably in dictionary.
That is how the machine was called "linus", and the primary box I use at home is "alter". My general purpose notebook is called "wing" (named after its manufacturer—can you guess who?).
Needless to say, I already know the name of my next Git machine: dial.
How do you name your machine?
But the thing is, the requested name is not after Linus Torvalds. I name my machines using a dictionary. Let me explain how. I name my machines after some theme, and the machine "linus", just like my primary box "alter", is named after the primary activity I was planning to do on it, namely "Git".
The first thing to do is to find a bunch of dictionary words that have G, I and T in this order. We may find these words: afGhanIsTan, linGuIsT, aGlITter,...
Then remove these G, I and T from these dictionary words to obtain: afhansan, linus, alter,...
Finally, pick ones that can be pronounced and preferrably in dictionary.
That is how the machine was called "linus", and the primary box I use at home is "alter". My general purpose notebook is called "wing" (named after its manufacturer—can you guess who?).
Needless to say, I already know the name of my next Git machine: dial.
How do you name your machine?
Sunday, April 29, 2012
Rebuilding Git Integration Environment
About ten days ago, after getting to the office, I found that my home box that I use as the primary integration machine was not responding. Later in the day, wife calls from home saying that the box is dead and does not even respond to the power button.
So until I had a chance to look at the box and resurrect it, I had to build the Git Integration Environment elsewhere. As Linus famously said once, only wimps use backup and real men just upload their important stuff and let the rest of the world mirror it ;-). All of my integration branches are pushed to multiple places, and one of the public repositories even have all of the topic branches, so it is just the matter of fetching them back. Other people could even try to imitate what I do by following this procedure.
First, grab all the branches I had in the primary box from the mirror:
$ git init git.git
$ cd git.git
$ git fetch --update-head-ok git://github.com/gitster/git refs/*:refs/*
$ git reset --hard master
So until I had a chance to look at the box and resurrect it, I had to build the Git Integration Environment elsewhere. As Linus famously said once, only wimps use backup and real men just upload their important stuff and let the rest of the world mirror it ;-). All of my integration branches are pushed to multiple places, and one of the public repositories even have all of the topic branches, so it is just the matter of fetching them back. Other people could even try to imitate what I do by following this procedure.
First, grab all the branches I had in the primary box from the mirror:
$ git init git.git
$ cd git.git
$ git fetch --update-head-ok git://github.com/gitster/git refs/*:refs/*
$ git reset --hard master
Unfortunately, GitHub adds garbage refs to my repository that I didn't push; I can eradicate them like this, but this step is not strictly necessary:
$ for x in $(git for-each-ref --format='%(refname)' refs/pull/)
do
git update-ref -d $x
done
After this, I can start building Git from tips of topic branches as usual, but my usual procedure is to make heavy use of helper scripts in the 'todo' branch that is checked out in the Meta directory (e.g. I run Meta/Make instead of make from the top-level, and that Make script is in the 'todo' branch).
$ git init Meta
$ (cd Meta && git pull git://git.kernel.org/pub/scm/git/git.git todo:master)
$ Meta/Make test install
$ Meta/Make test install
Among the helper scripts on the 'todo' branch (and checked out in the Meta directory) is the Reintegrate script. This is used to maintain redo-jch.sh and redo-pu.sh scripts I rebuild 'jch' and 'pu' branches with.
$ Meta/Reintegrate master..jch >Meta/redo-jch.sh
$ Meta/Reintegrate jch..pu >Meta/redo-pu.sh
$ chmod +x Meta/redo-*.sh
What is still missing after the above is the contents of the rerere database. This mechanism remembers the manual conflict resolution I had to perform when I built the integration branches (i.e. 'next', 'pu' and 'jch') earlier. Luckily, there is a script to do so in contrib/ since Sep 2008:
$ PATH=$PATH:. contrib/rerere-train.sh master..pu
This populates the rerere database by learning from the merge commits between 'master' and 'pu' branches, so after that, I can try rebuilding 'pu', like this:
$ git checkout master^0 ;# I am not really rebuilding--just "try rebuilding"
$ Meta/redo-jch.sh ;# replay all the merges that should go to the jch branch
$ Meta/redo-pu.sh ;# and then the merges to the pu branch on top
$ git diff HEAD pu ;# there should be no differences
After this, I can look at individual topics, decide which topics are worthy to be merged to 'next' or 'master', and advance tips of these integration branches with appropriate invocations of the git merge commands.
By the way, it turns out that the breakage was a failed power supply. I ordered one from NewEgg, which arrived early last week, but I procrastinated until this morning to replace it. After the necessary hardware swap, running the above procedure again to get the environment back was more or less trivial.
So, it's Baaack ;-)
Thursday, April 26, 2012
Git 1.7.7.7, 1.7.8.6 and 1.7.9.7
New releases for the three older maintenance tracks have been tagged and tarballs uploaded. They were mostly to push out small documentation fixes that have already been in the 'master' branch for the next feature release, except for v1.7.9.7, which has a fix for performance regression in "git fetch" introduced some time ago where the command wastes cycles to verify the connectivity of objects received from the other end, being unnecessarily pessimistic.
Friday, April 6, 2012
Git 1.7.10
After slipping for about a week, 1.7.10 final has been tagged.
The most notable change is that from this release, git merge will start opening the editor just like git commit does. See earlier articles for details.
Git v1.7.10 Release Notes
=========================
Compatibility Notes
-------------------
* From this release on, the "git merge" command in an interactive
session will start an editor when it automatically resolves the
merge for the user to explain the resulting commit, just like the
"git commit" command does when it wasn't given a commit message.
If you have a script that runs "git merge" and keeps its standard
input and output attached to the user's terminal, and if you do not
want the user to explain the resulting merge commits, you can
export GIT_MERGE_AUTOEDIT environment variable set to "no", like
this:
#!/bin/sh
GIT_MERGE_AUTOEDIT=no
export GIT_MERGE_AUTOEDIT
to disable this behavior (if you want your users to explain their
merge commits, you do not have to do anything). Alternatively, you
can give the "--no-edit" option to individual invocations of the
"git merge" command if you know everybody who uses your script has
Git v1.7.8 or newer.
* The "--binary/-b" options to "git am" have been a no-op for quite a
while and were deprecated in mid 2008 (v1.6.0). When you give these
options to "git am", it will now warn and ask you not to use them.
* When you do not tell which branches and tags to push to the "git
push" command in any way, the command used "matching refs" rule to
update remote branches and tags with branches and tags with the
same name you locally have. In future versions of Git, this will
change to push out only your current branch according to either the
"upstream" or the "current" rule. Although "upstream" may be more
powerful once the user understands Git better, the semantics
"current" gives is simpler and easier to understand for beginners
and may be a safer and better default option. We haven't decided
yet which one to switch to.
Updates since v1.7.9
--------------------
UI, Workflows & Features
* various "gitk" updates.
- show the path to the top level directory in the window title
- update preference edit dialog
- display file list correctly when directories are given on command line
- make "git-describe" output in the log message into a clickable link
- avoid matching the UNIX timestamp part when searching all fields
- give preference to symbolic font names like sans & monospace
- allow comparing two commits using a mark
- "gitk" honors log.showroot configuration.
* Teams for localizing the messages from the Porcelain layer of
commands are starting to form, thanks to Jiang Xin who volunteered
to be the localization coordinator. Translated messages for
simplified Chinese, Swedish and Portuguese are available.
* The configuration mechanism learned an "include" facility; an
assignment to the include.path pseudo-variable causes the named
file to be included in-place when Git looks up configuration
variables.
* A content filter (clean/smudge) used to be just a way to make the
recorded contents "more useful", and allowed to fail; a filter can
now optionally be marked as "required".
* Options whose names begin with "--no-" (e.g. the "--no-verify"
option of the "git commit" command) can be negated by omitting
"no-" from its name, e.g. "git commit --verify".
* "git am" learned to pass "-b" option to underlying "git mailinfo", so
that a bracketed string other than "PATCH" at the beginning can be kept.
* "git clone" learned "--single-branch" option to limit cloning to a
single branch (surprise!); tags that do not point into the history
of the branch are not fetched.
The most notable change is that from this release, git merge will start opening the editor just like git commit does. See earlier articles for details.
Git v1.7.10 Release Notes
=========================
Compatibility Notes
-------------------
* From this release on, the "git merge" command in an interactive
session will start an editor when it automatically resolves the
merge for the user to explain the resulting commit, just like the
"git commit" command does when it wasn't given a commit message.
If you have a script that runs "git merge" and keeps its standard
input and output attached to the user's terminal, and if you do not
want the user to explain the resulting merge commits, you can
export GIT_MERGE_AUTOEDIT environment variable set to "no", like
this:
#!/bin/sh
GIT_MERGE_AUTOEDIT=no
export GIT_MERGE_AUTOEDIT
to disable this behavior (if you want your users to explain their
merge commits, you do not have to do anything). Alternatively, you
can give the "--no-edit" option to individual invocations of the
"git merge" command if you know everybody who uses your script has
Git v1.7.8 or newer.
* The "--binary/-b" options to "git am" have been a no-op for quite a
while and were deprecated in mid 2008 (v1.6.0). When you give these
options to "git am", it will now warn and ask you not to use them.
* When you do not tell which branches and tags to push to the "git
push" command in any way, the command used "matching refs" rule to
update remote branches and tags with branches and tags with the
same name you locally have. In future versions of Git, this will
change to push out only your current branch according to either the
"upstream" or the "current" rule. Although "upstream" may be more
powerful once the user understands Git better, the semantics
"current" gives is simpler and easier to understand for beginners
and may be a safer and better default option. We haven't decided
yet which one to switch to.
Updates since v1.7.9
--------------------
UI, Workflows & Features
* various "gitk" updates.
- show the path to the top level directory in the window title
- update preference edit dialog
- display file list correctly when directories are given on command line
- make "git-describe" output in the log message into a clickable link
- avoid matching the UNIX timestamp part when searching all fields
- give preference to symbolic font names like sans & monospace
- allow comparing two commits using a mark
- "gitk" honors log.showroot configuration.
* Teams for localizing the messages from the Porcelain layer of
commands are starting to form, thanks to Jiang Xin who volunteered
to be the localization coordinator. Translated messages for
simplified Chinese, Swedish and Portuguese are available.
* The configuration mechanism learned an "include" facility; an
assignment to the include.path pseudo-variable causes the named
file to be included in-place when Git looks up configuration
variables.
* A content filter (clean/smudge) used to be just a way to make the
recorded contents "more useful", and allowed to fail; a filter can
now optionally be marked as "required".
* Options whose names begin with "--no-" (e.g. the "--no-verify"
option of the "git commit" command) can be negated by omitting
"no-" from its name, e.g. "git commit --verify".
* "git am" learned to pass "-b" option to underlying "git mailinfo", so
that a bracketed string other than "PATCH" at the beginning can be kept.
* "git clone" learned "--single-branch" option to limit cloning to a
single branch (surprise!); tags that do not point into the history
of the branch are not fetched.
* "git clone" learned to detach the HEAD in the resulting repository
when the user specifies a tag with "--branch" (e.g., "--branch=v1.0").
Clone also learned to print the usual "detached HEAD" advice in such
a case, similar to "git checkout v1.0".
* When showing a patch while ignoring whitespace changes, the context
lines are taken from the postimage, in order to make it easier to
view the output.
* "git diff --stat" learned to adjust the width of the output on
wider terminals, and give more columns to pathnames as needed.
* "diff-highlight" filter (in contrib/) was updated to produce more
aesthetically pleasing output.
* "fsck" learned "--no-dangling" option to omit dangling object
information.
* "git log -G" and "git log -S" learned to pay attention to the "-i"
option. With "-i", "log -G" ignores the case when finding patch
hunks that introduce or remove a string that matches the given
pattern. Similarly with "-i", "log -S" ignores the case when
finding the commit the given block of text appears or disappears
from the file.
* "git merge" in an interactive session learned to spawn the editor
by default to let the user edit the auto-generated merge message,
to encourage people to explain their merges better. Legacy scripts
can export GIT_MERGE_AUTOEDIT=no to retain the historical behavior.
Both "git merge" and "git pull" can be given --no-edit from the
command line to accept the auto-generated merge message.
* The advice message given when the user didn't give enough clue on
what to merge to "git pull" and "git merge" has been updated to
be more concise and easier to understand.
* "git push" learned the "--prune" option, similar to "git fetch".
* The whole directory that houses a top-level superproject managed by
"git submodule" can be moved to another place.
* "git symbolic-ref" learned the "--short" option to abbreviate the
refname it shows unambiguously.
* "git tag --list" can be given "--points-at
Tuesday, April 3, 2012
This time, it will be really final rc before Git 1.7.10
The upcoming version 1.7.10 of Git was scheduled to be tagged on Sunday, but I did not want to make important decisions or announces over the weekend to avoid making people wonder if anything I say is an April Fools joke.
That was an excuse for slipping the release a bit, but as a nice side effect, it paid off. Over the weekend, a few patches and a pull request worthy to be in the upcoming release came. A couple of rather embarrassing last-minute bugs were found and fixed in the updated gitk, and we have Portuguese translation of the messages.
So I am issuing another release candidate 1.7.10-rc4, hoping that people can test it out to find any other last-minute regressions, so that we can release the real 1.7.10 by the end of this week.
That was an excuse for slipping the release a bit, but as a nice side effect, it paid off. Over the weekend, a few patches and a pull request worthy to be in the upcoming release came. A couple of rather embarrassing last-minute bugs were found and fixed in the updated gitk, and we have Portuguese translation of the messages.
So I am issuing another release candidate 1.7.10-rc4, hoping that people can test it out to find any other last-minute regressions, so that we can release the real 1.7.10 by the end of this week.
Wednesday, March 28, 2012
Hopefully Final rc before Git 1.7.10
Git 1.7.10-rc3 has been tagged and users are strongly encouraged to download and test it before the final release happens. The tarballs are found at http://code.google.com/p/git-core/downloads/list and people fetching them using Git can find it in my public repositories.
Among the many improvements in the upcoming release is an update to the git merge command. While this has been received very favorably, it may surprise you when you run it for the first time, and is worth mentioning.
Traditionally, when the git merge command attempted to merge two or more histories, it prepared a canned commit log message based on what is being merged, and recorded the result in a merge commit without any user intervention, if the automatic merge logic successfully computed the resulting tree without conflict. When the automatic logic did not manage to come up with a clean merge result, it gave up, leaving the conflicted state in the index and in the working tree files, and asked the user to resolve them and run the git commit command to record the outcome.
Most merges do cleanly resolve, and this behavior resulted in people making their merges too easily and lightly, even when the reason why the merge was made in the first place should be explained. Nobody explained why the merge was made in a merge commit, because in order to do so after git merge already made the commit, they have to go back and run git commit --amend to do so.
Recently in a discussion on the Git mailing list, Linus admitted (and I agreed) that this was one of the design mistakes we made early in the history of Git. And in 1.7.10 and later, the git merge command that is run in an interactive session (i.e. both its standard input and its standard output connected to a terminal) will open an editor before creating a commit to record the merge result, to give the user a chance to explain the merge, just like the git commit command the user runs after resolving a conflicted merge already does.
A quick way to update your scripts that shouldn't let its users explain the merges created by them is to set and export an environment variable, like this.
#!/bin/sh
Among the many improvements in the upcoming release is an update to the git merge command. While this has been received very favorably, it may surprise you when you run it for the first time, and is worth mentioning.
Traditionally, when the git merge command attempted to merge two or more histories, it prepared a canned commit log message based on what is being merged, and recorded the result in a merge commit without any user intervention, if the automatic merge logic successfully computed the resulting tree without conflict. When the automatic logic did not manage to come up with a clean merge result, it gave up, leaving the conflicted state in the index and in the working tree files, and asked the user to resolve them and run the git commit command to record the outcome.
Most merges do cleanly resolve, and this behavior resulted in people making their merges too easily and lightly, even when the reason why the merge was made in the first place should be explained. Nobody explained why the merge was made in a merge commit, because in order to do so after git merge already made the commit, they have to go back and run git commit --amend to do so.
Recently in a discussion on the Git mailing list, Linus admitted (and I agreed) that this was one of the design mistakes we made early in the history of Git. And in 1.7.10 and later, the git merge command that is run in an interactive session (i.e. both its standard input and its standard output connected to a terminal) will open an editor before creating a commit to record the merge result, to give the user a chance to explain the merge, just like the git commit command the user runs after resolving a conflicted merge already does.
A quick way to update your scripts that shouldn't let its users explain the merges created by them is to set and export an environment variable, like this.
#!/bin/sh
GIT_MERGE_AUTOEDIT=no
export GIT_MERGE_AUTOEDIT
export GIT_MERGE_AUTOEDIT
# whatever your script did originally
...
git merge foo
git merge bar
Subscribe to:
Comments (Atom)