I've got a branch for each bug/issue and it was getting a bit
unwieldy. A little searching suggested this
# archive off the BUG-123 branch
git update-ref refs/closed/BUG-123 BUG-123
git branch -D BUG-123
which seems to do exactly what I want -- branches are archived off so
they still have
On 2014-04-23 10:58, Jonathan Nieder wrote:
Tim Chase wrote:
cd .git/refs
mkdir -p closed
mv heads/BUG-123 closed
That breaks with packed refs (see git-pack-refs(1)), which are a
normal thing to encounter after garbage collection.
Hope that helps,
Very much so. Alrighty
On 2014-04-11 13:32, Javier Domingo Cansino wrote:
I have never thought on that logo as the Git logo (the red one), and
thought it was [1]. Mainly because the logo itself has git inside.
[1] Git logo:
http://git-osx-installer.googlecode.com/files/GitLogo.jpg --
Like Javier, I too assumed
This crossed my path recently via the fossil mailing list
http://git-man-page-generator.lokaltog.net/
but I thought folks here might enjoy the humor :-)
(and I hadn't seen mention of it here on the list yet)
-tkc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
On 2014-03-16 23:37, Junio C Hamano wrote:
Tim Chase g...@tim.thechases.com writes:
Is this just an interface inconsistency or is there a some
technical reason this doesn't work (or, has it been
addressed/fixed, and just not pulled into Debian Stable's
1.7.10.4 version of git
I recently learned that there are several places where git allows use
of - to refer to the previous branch, e.g.
git checkout -b dev
# hack, hack
git checkout master
git merge -
git checkout -
However, it doesn't seem to understand - in the context of a rebase:
git checkout branch_a
Is there any way to associate some sort of note with a branch that
would be shown when listing them? While I currently have things like
issue/QA-42, it would be nice to have a note associated with it so
I could do something like
$ git branch --show-notes
issue/CR-88: make sure NoSQL
On 2013-11-25 15:55, Johan Herland wrote:
git branch --edit-description allows you to write a descriptive
string for your branch. AFAICS, however, it currently only shows up
when using request-pull. It does not show up in any git branch
command. IMHO that should be fixed.
As a workaround,
Having lost add -p work enough times when stashing, I finally
dug into the docs to see how to prevent it, discovering that
--keep-index does exactly what I want. However, now I have trouble
remembering to add the --keep-index until after I've shot myself in
the foot. How do I go about getting
Has there been any development on git-fossil bridging? I know one
can spew fastimports between the two for an initial synchronization,
but I'd like to have a continuous bridge; something like git-svn.
I have fossil on one machine (mostly a public machine, for
bug-tracking, wiki, etc that fossil
On 2013-11-17 14:43, Kyle J. McKay wrote:
Sounds like you want to write a 'git-remote-fossil' helper so you
can do something like:
git clone fossil::http://sqlite.org/src
Pretty much. Or at least something akin to git-svn where one would do
git fossil clone
On 2013-09-06 12:39, Tay Ray Chuan wrote:
First: recognize Mercurial's branches are entirely different beasts
from Git's. They just happen to be given a same sequence of
characters, b-r-a-n-c-h. The similarities end there!
Yeah, I'm trying to create a mental map between what Git means by
On 2013-09-06 17:51, Konstantin Khomoutov wrote:
I found this guide [1] very useful back in the time I tried to grok
Mercurial.
1.
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
Indeed, after reading it, that's the most sense I've been able to make
of Mercurial's
I've got a pretty good grasp on git's rather straightforward
branching, but am trying to wrap my head around Mercurial's
branching. There seem to be several flavors, some default to
push-public, while others are private; some are tracked in history,
while others seem more ephemeral; often the
On 2013-08-14 12:49, Tim Chase wrote:
c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1
but get various failures. My best-effort (above) gets me as far as
actually starting some sort of clone but it dies with
Permission denied: Can't open '/tmp/report.tmp': Permission
On 2013-08-15 09:00, John Keeping wrote:
On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote:
On 2013-08-14 12:49, Tim Chase wrote:
If it makes any difference, this is within a cmd.exe shell (with
$PATH set appropriately so git is being found).
Just a follow-up, I tried
On 2013-08-15 12:35, John Keeping wrote:
Just a follow-up, I tried it within the bashish shell
included in the git install and got the same error regarding
/tmp/report.tmp.
It seems that report.tmp is something that SVN creates and for
some reason the svn on your system is trying to create
I've been sparring with the proper syntax and hope someone can give
me the magic I'm missing. I want to do something of the form
c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1
but get various failures. My best-effort (above) gets me as far as
actually starting some sort
On 2013-08-14 12:49, Tim Chase wrote:
If it makes any difference, this is within a cmd.exe shell (with
$PATH set appropriately so git is being found).
Just a follow-up, I tried it within the bashish shell included in
the git install and got the same error regarding /tmp/report.tmp.
-tkc
On 2013-06-27 20:46, Woody Wu wrote:
I have a colleague who has to left our office for three month, but
still need to work on the project which is hosted on our in-office
git repository. Problem is that our company has firewall, it's not
possible or not allowed to access the company LAN
On 2013-04-16 19:29, David Aguilar wrote:
On Tue, Apr 16, 2013 at 6:38 PM, Tim Chase g...@tim.thechases.com
wrote:
git commit -am Long-bodied commit comment about b.txt changes
# whoops, just wanted B
Save the commit's ID here so that we can reuse its message later:
orig_commit
Various programs that I use ([Open|Libre]Office, Vym, etc) use a
zipped/.tgz'ed file format, usually containing multiple
(usually) plain-text files within.
I'm trying to figure out a way for git to treat these as virtual
directories for purposes of merging/diffing.
Reading up on clean/smudge
On 2013-02-17 16:52, Junio C Hamano wrote:
* Color specifiers, e.g. %C(blue)Hello%C(reset), used in the
--format= option of git log and friends can be disabled when
the output is not sent to a terminal by prefixing them with
auto,, e.g. %C(auto,blue)Hello%C(auto,reset).
Thanks so
[tried IRC to no avail]
I've been trying to find a way to prevent myself from merging a
client-specific branch back into my dev/master branches. Is there an
easy/straightforward way to do this (perhaps via a hook)? I didn't
see any sort of pre-merge hook script. Visualized:
A - B - C [dev]
The documentation for gitweb gives one description of the default
content for the $GIT/description, the description template has other
text. One of these two patches should be applied to bring them into
order (applying both would just reverse the problem). Or, both
could be changed to the
On 01/10/13 20:22, Jonathan Nieder wrote:
(+cc: Jakub, who maintains gitweb)
Hi Tim,
Tim Chase wrote:
The documentation for gitweb gives one description of the default
content for the $GIT/description, the description template has other
text. One of these two patches should be applied
On 08/24/12 09:29, Jeff King wrote:
On Tue, Aug 21, 2012 at 10:52:03AM -0700, Junio C Hamano wrote:
diff.{type}.xfuncname seems to start searching backwards in
from the beginning of the hunk, not the first differing line.
[...]
@@ -4,4 +4,5 @@ int call_me(int maybe)
int main()
{
On 08/24/12 11:44, Jeff King wrote:
With the old code, you'd get:
diff --git a/old b/new
index f384549..1066a25 100644
--- a/old
+++ b/new
@@ -2,3 +2,3 @@ one
two
-three
+three -- modified
four
So the hunk header is showing you
[posted originally to git-users@ but advised this would be a better
forum]
diff.{type}.xfuncname seems to start searching backwards in
from the beginning of the hunk, not the first differing line.
To reproduce:
$ mkdir tmp
$ cd tmp
$ git init
$ cat foo.c EOF
int call_me(int maybe)
[posted originally to git-users@ but advised this would be a better
forum]
diff.{type}.xfuncname seems to start searching backwards in
from the beginning of the hunk, not the first differing line.
To reproduce:
$ mkdir tmp
$ cd tmp
$ git init
$ cat foo.c EOF
int call_me(int maybe)
On 08/21/12 10:22, Thomas Rast wrote:
Tim Chase g...@tim.thechases.com writes:
diff.{type}.xfuncname seems to start searching backwards in
from the beginning of the hunk, not the first differing line.
[...]
@@ -4,4 +4,5 @@ int call_me(int maybe)
int main()
{
+ return 0
31 matches
Mail list logo
