* Re: What's The Right Way to Do This?
From: Johannes Sixt @ 2011-09-23 6:39 UTC (permalink / raw)
To: Jon Forrest; +Cc: git
In-Reply-To: <loom.20110923T064720-366@post.gmane.org>
Am 9/23/2011 6:48, schrieb Jon Forrest:
> I'm just now starting to use git for more than trivial things.
> Today I got myself in trouble. Here's what happened:
>
> 1) I pulled the master branch from the IT repository from our
> main git server.
>
> 2) I created a branch from this called "J" and started making changes.
>
> 3) Other people pulled master from IT and then pushed changes back.
OK, so you are basically using a central repo.
> 4) I merged J with my master branch.
>
> 5) I tried pushing my master back to origin but this failed with
> the usual message saying I first needed to pull from origin.
> So, I pulled and then pushed. This worked.
>
> 6) On another server where I was going to use my changes I pulled
> master from IT.
I assume you mention this because with this step you detected that your
changes were crap.
> 6) It turned out that my changes were incorrect. So, I tried to revert
> using various methods I found by googling "git revert". What happened
> was that when I tried to revert back to the commit before the one I
> made, the files I had modified *and* the files that apparently were
> modified by other people in #3 above were reverted. This wasn't what
> I wanted. I only wanted to revert the changes I had made.
It looks like you had reset the history, not just reverted your changes.
> With the help of someone more experienced than me we were able to get
> things back to normal but this experience left me wondering what I
> should have done in the first place. There's a chance I'm going to
> have to go through all this again as I try to fix the problem with
> my changes.
With a central repository, any push into it marks a "done deal". No matter
how wrong and bogus your changes are, as soon as you push them into the
central repository, they are cast in stone.
At this point, the best you can do is to revert you changes, and by this I
mean that you create and push out another commit on top that backs out the
changes that you made.
If this is not what you (or your team) wants, than the problem is not with
suboptimal use of the git toolset, but with the push policy within you
team. A good policy should forbid that untested stuff can be pushed into
the central repository.
My suggestion is that you find a way to move your changes to the test site
(the "another server" you mention in step 6) without going through the
central repository. For example, if you have ssh access between your
development machine and the test site, you can push or pull your changes
between them directly.
-- Hannes
^ permalink raw reply
* Re: What's The Right Way to Do This?
From: Luke Diamand @ 2011-09-23 6:30 UTC (permalink / raw)
To: Jon Forrest; +Cc: git
In-Reply-To: <loom.20110923T064720-366@post.gmane.org>
On 23/09/11 05:48, Jon Forrest wrote:
> I'm just now starting to use git for more than trivial things.
> Today I got myself in trouble. Here's what happened:
>
> 1) I pulled the master branch from the IT repository from our
> main git server.
>
> 2) I created a branch from this called "J" and started making changes.
>
> 3) Other people pulled master from IT and then pushed changes back.
>
> 4) I merged J with my master branch.
Someone will be along soon to correct me, but I think you should have
rebased against the master branch rather than merged. Something like:
% git rebase origin
That way your changes would remain appended to the tip of the master
branch. That will in general make your life much easier for all sorts of
reasons.
>
> 5) I tried pushing my master back to origin but this failed with
> the usual message saying I first needed to pull from origin.
> So, I pulled and then pushed. This worked.
>
> 6) On another server where I was going to use my changes I pulled
> master from IT.
>
> 6) It turned out that my changes were incorrect. So, I tried to revert
> using various methods I found by googling "git revert". What happened
> was that when I tried to revert back to the commit before the one I
> made, the files I had modified *and* the files that apparently were
> modified by other people in #3 above were reverted. This wasn't what
> I wanted. I only wanted to revert the changes I had made.
At a guess, git revert created a commit that undid your _merge_, rather
than your commit. The merge included all those other changes....
It's a good idea to take a look at what a commit does before pushing it
- "git show HEAD" is your friend.
>
> With the help of someone more experienced than me we were able to get
> things back to normal but this experience left me wondering what I
> should have done in the first place. There's a chance I'm going to
> have to go through all this again as I try to fix the problem with
> my changes.
Use git rebase (*) to keep your changes nicely arranged at the top of
the main branch.
Use git show to check the sanity of what you're about to push upstream.
I think you could award yourself a nice cup of tea after an experience
like that though, having been on both sides of it, I can imagine you
need it :-P
Regards!
Luke
(*) But note that rebasing can cause problems for people who are
downstream of _you_. See the git-rebase(1) man page.
^ permalink raw reply
* Re: Bug: git log --numstat counts wrong
From: Tay Ray Chuan @ 2011-09-23 6:30 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, Alexander Pepper, git
In-Reply-To: <4E7B5F28.2020204@lsrfire.ath.cx>
On Fri, Sep 23, 2011 at 12:15 AM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> The patch below reverts a part of 27af01d5523 that's not explained in its
> commit message and doesn't seem to contribute to the intended speedup. It
> seems to restore the original diff output. I don't know how it's actually
> doing that, though, as I haven't dug into the code at all.
>
> [snip]
>
> diff --git a/xdiff/xprepare.c b/xdiff/xprepare.c
> index 5a33d1a..e419f4f 100644
> --- a/xdiff/xprepare.c
> +++ b/xdiff/xprepare.c
> @@ -383,7 +383,7 @@ static int xdl_clean_mmatch(char const *dis, long i, long s, long e) {
> * might be potentially discarded if they happear in a run of discardable.
> */
> static int xdl_cleanup_records(xdlclassifier_t *cf, xdfile_t *xdf1, xdfile_t *xdf2) {
> - long i, nm, nreff;
> + long i, nm, nreff, mlim;
> xrecord_t **recs;
> xdlclass_t *rcrec;
> char *dis, *dis1, *dis2;
> @@ -396,16 +396,20 @@ static int xdl_cleanup_records(xdlclassifier_t *cf, xdfile_t *xdf1, xdfile_t *xd
> dis1 = dis;
> dis2 = dis1 + xdf1->nrec + 1;
>
> + if ((mlim = xdl_bogosqrt(xdf1->nrec)) > XDL_MAX_EQLIMIT)
> + mlim = XDL_MAX_EQLIMIT;
> for (i = xdf1->dstart, recs = &xdf1->recs[xdf1->dstart]; i <= xdf1->dend; i++, recs++) {
> rcrec = cf->rcrecs[(*recs)->ha];
> nm = rcrec ? rcrec->len2 : 0;
> - dis1[i] = (nm == 0) ? 0: 1;
> + dis1[i] = (nm == 0) ? 0: (nm >= mlim) ? 2: 1;
> }
>
> + if ((mlim = xdl_bogosqrt(xdf2->nrec)) > XDL_MAX_EQLIMIT)
> + mlim = XDL_MAX_EQLIMIT;
> for (i = xdf2->dstart, recs = &xdf2->recs[xdf2->dstart]; i <= xdf2->dend; i++, recs++) {
> rcrec = cf->rcrecs[(*recs)->ha];
> nm = rcrec ? rcrec->len1 : 0;
> - dis2[i] = (nm == 0) ? 0: 1;
> + dis2[i] = (nm == 0) ? 0: (nm >= mlim) ? 2: 1;
> }
>
> for (nreff = 0, i = xdf1->dstart, recs = &xdf1->recs[xdf1->dstart];
>
>
>
Thanks for the patch, René.
Sorry for not explaining that part of the change.
My understanding of mlim is that it "caps" how deep the for loop at
around line 387 goes through a hash bucket/record chaing to find a
matching record from side A in side B (and vice-versa in a later
loop), probably to prevent running time from becoming too long.
But with 27af01d, this is no longer a concern. We can get an *exact*,
pre-computed count of matching records in the other side, so we don't
have go through the hash bucket. Thus mlim is no longer needed.
So re-introducing mlim doesn't seem right, even though it may fix this
"bug" (ie restore the old behaviour).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Jay Soffian @ 2011-09-23 5:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Michael Haggerty
In-Reply-To: <CAG+J_DzUQ3OGfiX=vHVGC7SHvwToVjD7uwFyDa8Tq6t7YwX12Q@mail.gmail.com>
On Thu, Sep 22, 2011 at 8:38 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Thu, Sep 22, 2011 at 6:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> I think the logical conclusion of assuming that we will keep the "single
>> source only" semantics (which I think we will, by the way, unless I hear a
>> concrete proposal to how we apply attributes from more than one sources in
>> what way to which side of the diff) is that a patch might be an
>> improvement over the current behaviour if it teaches "diff-tree" to read
>> from the tree and populate the in-core index (never writing it out to
>> $GIT_DIR/index) from the postimage tree (i.e. "diff preimage postimage" or
>> "diff -R postimage preimage") when it is run in a bare repository.
>
> Okay, I can give that a try.
This area of git is still black magic to me. My best guess is
something like this:
diff --git a/tree-diff.c b/tree-diff.c
index b3cc2e4753..6fd84eb2bb 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -5,6 +5,8 @@
#include "diff.h"
#include "diffcore.h"
#include "tree.h"
+#include "attr.h"
+#include "unpack-trees.h"
static void show_entry(struct diff_options *opt, const char *prefix,
struct tree_desc *desc, struct strbuf *base);
@@ -280,6 +282,19 @@ int diff_tree_sha1(const unsigned char *old,
const unsigned char *new, const cha
die("unable to read destination tree (%s)", sha1_to_hex(new));
init_tree_desc(&t1, tree1, size1);
init_tree_desc(&t2, tree2, size2);
+
+ if (is_bare_repository()) {
+ struct unpack_trees_options unpack_opts;
+ memset(&unpack_opts, 0, sizeof(unpack_opts));
+ unpack_opts.index_only = 1;
+ unpack_opts.head_idx = -1;
+ unpack_opts.src_index = &the_index;
+ unpack_opts.dst_index = &the_index;
+ unpack_opts.fn = oneway_merge;
+ if (unpack_trees(1, DIFF_OPT_TST(opt, REVERSE_DIFF) ? &t1 : &t2,
&unpack_opts) == 0)
+ git_attr_set_direction(GIT_ATTR_INDEX, &the_index);
+ }
+
retval = diff_tree(&t1, &t2, base, opt);
if (!*base && DIFF_OPT_TST(opt, FOLLOW_RENAMES) && diff_might_be_rename()) {
init_tree_desc(&t1, tree1, size1);
(And in case gmail line wraps that -- https://gist.github.com/1236806)
Am I barking up the right tree? (Obviously still needs tests, and
maybe an --[no]-tree-attributes option.)
j.
^ permalink raw reply related
* Re: What's The Right Way to Do This?
From: Michael Witten @ 2011-09-23 5:08 UTC (permalink / raw)
To: Jon Forrest; +Cc: git
In-Reply-To: <loom.20110923T064720-366@post.gmane.org>
On Fri, Sep 23, 2011 at 04:48, Jon Forrest <nobozo@gmail.com> wrote:
> ... So, I tried to revert using various methods I found by
> googling "git revert"...
> ...
> ...this experience left me wondering what I should have
> done in the first place.
What you should have done in the first place is RTFM; while
not fantastic, there is a decent amount of official git
documentation.
> What happened was that when I tried to revert back to the
> commit before the one I made, the files I had modified
> *and* the files that apparently were modified by other
> people in #3 above were reverted. This wasn't what
> I wanted. I only wanted to revert the changes I had made.
It would be a good idea to reproduce the unexpected behavior
you are experiencing by means of a minimal set of commands
that you can post here for others to try.
> With the help of someone more experienced than me we were
> able to get things back to normal... There's a chance I'm
> going to have to go through all this again as I try to fix
> the problem with my changes.
Why don't you ask that person about it?
^ permalink raw reply
* deleting non-existent ref via push
From: Sitaram Chamarty @ 2011-09-23 5:04 UTC (permalink / raw)
To: Git Mailing List
Hello,
Pushing to delete a non-existent ref (git push origin :refs/heads/foo)
works without error, except for a warning that the remote is "Allowing
deletion of corrupt ref". By "works" I mean all hooks are also
executed.
Is this expected/supported behaviour? Can I rely on it continuing to
work, especially in terms of executing hooks.
Seem like a great way to "poke" a remote repo into executing hooks
without having to make a dummy change and push :-)
--
Sitaram
^ permalink raw reply
* What's The Right Way to Do This?
From: Jon Forrest @ 2011-09-23 4:48 UTC (permalink / raw)
To: git
I'm just now starting to use git for more than trivial things.
Today I got myself in trouble. Here's what happened:
1) I pulled the master branch from the IT repository from our
main git server.
2) I created a branch from this called "J" and started making changes.
3) Other people pulled master from IT and then pushed changes back.
4) I merged J with my master branch.
5) I tried pushing my master back to origin but this failed with
the usual message saying I first needed to pull from origin.
So, I pulled and then pushed. This worked.
6) On another server where I was going to use my changes I pulled
master from IT.
6) It turned out that my changes were incorrect. So, I tried to revert
using various methods I found by googling "git revert". What happened
was that when I tried to revert back to the commit before the one I
made, the files I had modified *and* the files that apparently were
modified by other people in #3 above were reverted. This wasn't what
I wanted. I only wanted to revert the changes I had made.
With the help of someone more experienced than me we were able to get
things back to normal but this experience left me wondering what I
should have done in the first place. There's a chance I'm going to
have to go through all this again as I try to fix the problem with
my changes.
Any suggestions would be appreciated.
Thanks,
Jon Forrest
^ permalink raw reply
* permission to re-license archive-zip.c and zlib.c as LGPL
From: Brandon Casey @ 2011-09-23 3:51 UTC (permalink / raw)
To: rene.scharfe, Junio C Hamano, git, dpotapov, vagabon.xyz
To those who have contributed to archive-zip.c and zlib.c,
I'd like to make a library for writing zip files. I really don't see
another library out there that does it as easily as archive-zip. So,
with your consent, I'd like to re-license the code in archive-zip.c
and zlib.c as LGPL so that I can create an archive-zip library. The
reason for LGPL, of course, is so that it can be linked with non-GPL
code.
Please offer your consent to re-license your contributions under LGPL
by replying to this email.
All comments welcome.
Thanks,
-Brandon
^ permalink raw reply
* Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Jay Soffian @ 2011-09-23 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Michael Haggerty
In-Reply-To: <7v8vpgxkvb.fsf@alter.siamese.dyndns.org>
On Thu, Sep 22, 2011 at 6:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> When diff'ing the index against a tree (using either diff-index
>> or diff --cached), git previously looked at .gitattributes in the
>> working tree before considering .gitattributes in the index, even
>> though the diff itself otherwise ignores the working tree.
>
> We can take attributes only from one place (so far from the working tree
> and perhaps from the index), people had to live within the limitation that
> comes from the "single source only" semantics. It also happens to be
> easier to understand (recall the complexity of the examples Jeff gave
> about "textconv" during "diff" which ideally should apply from its own
> side and "funcname", which does not even have a right answer).
>
> In practice, because development progresses by making everything
> (including the .gitattributes file) better, I think "use the newer one"
> would be a good compromise when we have two possible sources to grab
> attributes from but we can only use one source.
I agree with that...
> In that sense, I am somewhat skeptical about what this patch tries to
> do. The working tree is where people make the progress to update the
> index.
... but it still seems inconsistent that --cached ignores the working
tree except for .gitattributes.
This also happens to be the only way to get diff-index to work with a
bare repo and temporary (on-disk) index. But that's less important if
we implement what's suggested in the next paragraph.
> A related tangent.
>
> I think the logical conclusion of assuming that we will keep the "single
> source only" semantics (which I think we will, by the way, unless I hear a
> concrete proposal to how we apply attributes from more than one sources in
> what way to which side of the diff) is that a patch might be an
> improvement over the current behaviour if it teaches "diff-tree" to read
> from the tree and populate the in-core index (never writing it out to
> $GIT_DIR/index) from the postimage tree (i.e. "diff preimage postimage" or
> "diff -R postimage preimage") when it is run in a bare repository.
Okay, I can give that a try.
> It
> would be a regression if the attributes mechanism is used for auditing
> purposes (as we start reading from a tree that is being audited using the
> very attributes it brings in), though.
--[no-]tree-attributes?
j.
^ permalink raw reply
* ( MESSAGE FROM TOKYO JAPAN)
From: Mr. Kang Hoon @ 2011-09-22 23:50 UTC (permalink / raw)
To: mrkanghoon@yahoo.com.hk
Hello,
Good day, how are you today hope healthy? Please my English speaking is not
very good, but I can write better than to speak.
I am Mr Kang Hoon, From Republic of Korea writing from Home Center Kohnan,
Koto Fukagawa (Tokyo) Japan. I worked as the general caretaker to
Mr.Masamichi Kazama, late Mr. Kazama, his a banker and real estate developer
living in Fukushima Japan but died during the tsunami disaster (earthquake)
in Fukushima Japan, I am the closes person that work with late Mr. Masamichi
Kazama before his death.
Mr. Masamichi Kazama have a safe deposit fund of US$22,600,000.00 with a
private vault house abroad and which I have the original certificate of
deposit with me for the claims, all I need from you is to contact the
private vault house abroad with prove of the certificate of deposit for the
released of the safe deposit in your favor. We share 60% for you and 40% for
me if you are interested contact me with my private email for more details
(infomrkanghoon@yahoo.com.hk )
Read more about lost of life's, peoples relatives lost businesses, huge
amount of money, properties and many more on the link below
http://www.huffingtonpost.com/2011/04/10/japan-lost-money-safes-cash_n_8472
43.html
I am waiting to hear from you.
Sincerely yours,
Mr. Kang Hoon
Tokyo - Japan.
This is a confidential message
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Junio C Hamano @ 2011-09-22 23:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201109230133.33214.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I don't think _modern_ distributions need this workaround... asciidoc 8.4.5
> which fixed the issue with "Synopsis" section was released 2009-05-24:
Thanks for a clarification. I'll then hold it off until the upcoming
release and then merge it to see if anybody screams.
^ permalink raw reply
* Re: [PATCH 1/2] Teach '--cached' option to check-attr
From: Junio C Hamano @ 2011-09-22 23:36 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Jeff King, Michael Haggerty
In-Reply-To: <1316727861-90460-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> This doesn't seem too controversial to me, and allows server-side
> reading of .gitattributes, albeit with the need to setup an index.
Thanks; will queue with a few trivial tweaks.
> +test_expect_success 'bare repository: check that --cached honors index' '
> +
> + export GIT_INDEX_FILE=../.git/index &&
> + git check-attr --cached --stdin --all < ../stdin-all |
> + sort > actual &&
> + test_cmp ../specified-all actual
> +
> +'
This is unfriendly to others who need to add more tests after this piece
by contaminating their environment. A single-shot export would be more
appropriate here:
GIT_INDEX_FILE=../.git/index git check-attr --cached ...
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Jakub Narebski @ 2011-09-22 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4o04xjcb.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> --------------------------------------------------
>>> [New Topics]
>>
>>> * jc/namespace-doc-with-old-asciidoc (2011-09-16) 1 commit
>>> - Documentation/gitnamespaces.txt: cater to older asciidoc
>>
>> I'll need this to e.g. test the "rpm" target after adding
>> Documentation/gitweb.txt and Documentation/gitweb.conf.txt
>>
>> But it is not something very urgent...
>
> Now I am confused. If you apply your patch on top of "master" then you
> cannot create "rpm" on your platform, not because your patch is busted,
> but because "master" lacks the documentation fix from that topic. Is that
> what you mean?
Yes, that is what I mean... but that it is only because I use old
version of asciidoc (7.1.2).
"make doc" (which is part of "make rpm") fails on my box with
ASCIIDOC gitnamespaces.html
ERROR: gitnamespaces.txt: line 9: second section must be named SYNOPSIS
make[1]: *** [gitnamespaces.html] Error 1
> If the reason the documentation fix for "master" is needed is because a
> new feature scheduled for the upcoming release has broken documentation,
> then wouldn't we need the fix before the release, whether you are working
> on your patch or not? How can it be not urgent if that is the case?
>
> On my boxes with recent Debian, Ubuntu, and F14, I am not suffering from
> the lack of the workaround, but if distros need the workaround, then the
> time to apply it is now, not post release.
I don't think _modern_ distributions need this workaround... asciidoc 8.4.5
which fixed the issue with "Synopsis" section was released 2009-05-24:
http://www.methods.co.nz/asciidoc/CHANGELOG.html
Version 8.4.5 (2009-05-24)
--------------------------
Additions and changes
~~~~~~~~~~~~~~~~~~~~~
* Added manpage "Name" and "Synopsis" section title customization to
languages configuration files.
* "Synopsis" manpage section no longer mandatory.
[...]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Junio C Hamano @ 2011-09-22 23:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3r538qj0j.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> --------------------------------------------------
>> [New Topics]
>
>> * jc/namespace-doc-with-old-asciidoc (2011-09-16) 1 commit
>> - Documentation/gitnamespaces.txt: cater to older asciidoc
>
> I'll need this to e.g. test the "rpm" target after adding
> Documentation/gitweb.txt and Documentation/gitweb.conf.txt
>
> But it is not something very urgent...
Now I am confused. If you apply your patch on top of "master" then you
cannot create "rpm" on your platform, not because your patch is busted,
but because "master" lacks the documentation fix from that topic. Is that
what you mean?
If the reason the documentation fix for "master" is needed is because a
new feature scheduled for the upcoming release has broken documentation,
then wouldn't we need the fix before the release, whether you are working
on your patch or not? How can it be not urgent if that is the case?
On my boxes with recent Debian, Ubuntu, and F14, I am not suffering from
the lack of the workaround, but if distros need the workaround, then the
time to apply it is now, not post release.
Hmmm....
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Jakub Narebski @ 2011-09-22 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa9xyxpf.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> --------------------------------------------------
> [New Topics]
> * jc/namespace-doc-with-old-asciidoc (2011-09-16) 1 commit
> - Documentation/gitnamespaces.txt: cater to older asciidoc
I'll need this to e.g. test the "rpm" target after adding
Documentation/gitweb.txt and Documentation/gitweb.conf.txt
But it is not something very urgent; the series are cooking now:
"[PATCH/RFCv4 0/4] Moving gitweb documentation to manpages"
http://thread.gmane.org/gmane.comp.version-control.git/181605
--
Jakub Narębski
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jakub Narebski @ 2011-09-22 22:54 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git discussion list, Jay Soffian
In-Reply-To: <4E7AF1AE.5030005@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Thanks for the reply and for explaining how the index can(not) be used
> for this purpose. But what you propose is not flexible enough for me.
> I would like the checking configuration to be *versioned* along with the
> code. [...]
[...]
> For this to be possible, I would need to determine the git attributes to
> apply to a particular file in a particular commit; something like
>
> git check-attr check-space-indent $SHA1:path/to/file
>
> This does not seem to be possible today without writing my own code to
> crawl and parse the gitattributes files from a particular commit.
Unfortunately it doesn't seem to be there mechanism to query about
state of gitattributes at given commit.
There is a slight problem from the UI point of view of git-check-attr,
namely that there are _three_ pieces of information: a place to read
.gitattributes from (working tree, index, commit), list of attributes
to check (or --all) and list of files (list of paths). You can use
"--" to separate _two_ pieces of information.
Nb. the ability to read gitattributes from given commit would be
useful also for gitweb (the `encoding` gitattribute, etc.).
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Junio C Hamano @ 2011-09-22 22:39 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Jeff King, Michael Haggerty
In-Reply-To: <1316727861-90460-2-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> When diff'ing the index against a tree (using either diff-index
> or diff --cached), git previously looked at .gitattributes in the
> working tree before considering .gitattributes in the index, even
> though the diff itself otherwise ignores the working tree.
We can take attributes only from one place (so far from the working tree
and perhaps from the index), people had to live within the limitation that
comes from the "single source only" semantics. It also happens to be
easier to understand (recall the complexity of the examples Jeff gave
about "textconv" during "diff" which ideally should apply from its own
side and "funcname", which does not even have a right answer).
In practice, because development progresses by making everything
(including the .gitattributes file) better, I think "use the newer one"
would be a good compromise when we have two possible sources to grab
attributes from but we can only use one source.
In that sense, I am somewhat skeptical about what this patch tries to
do. The working tree is where people make the progress to update the
index.
A related tangent.
I think the logical conclusion of assuming that we will keep the "single
source only" semantics (which I think we will, by the way, unless I hear a
concrete proposal to how we apply attributes from more than one sources in
what way to which side of the diff) is that a patch might be an
improvement over the current behaviour if it teaches "diff-tree" to read
from the tree and populate the in-core index (never writing it out to
$GIT_DIR/index) from the postimage tree (i.e. "diff preimage postimage" or
"diff -R postimage preimage") when it is run in a bare repository. It
would be a regression if the attributes mechanism is used for auditing
purposes (as we start reading from a tree that is being audited using the
very attributes it brings in), though.
^ permalink raw reply
* Re: [PATCH 2/2] fast-import: don't allow to note on empty branch
From: Sverre Rabbelier @ 2011-09-22 22:29 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, Jonathan Nieder, Shawn O. Pearce, David Barr
In-Reply-To: <1316720825-32552-3-git-send-email-divanorama@gmail.com>
Heya,
On Thu, Sep 22, 2011 at 21:47, Dmitry Ivankov <divanorama@gmail.com> wrote:
> 'reset' command makes fast-import start a branch from scratch. It's name
> is kept in lookup table but it's sha1 is null_sha1 (special value).
> 'notemodify' command can be used to add a note on branch head given it's
> name. lookup_branch() is used it that case and it doesn't check for
> null_sha1. So fast-import writes a note for null_sha1 object instead of
> giving a error.
>
> Add a check to deny adding a note on empty branch and add a corresponding
> test.
Makes sense as well.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/2] fast-import: don't allow to tag empty branch
From: Sverre Rabbelier @ 2011-09-22 22:28 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, Jonathan Nieder, Shawn O. Pearce, David Barr
In-Reply-To: <1316720825-32552-2-git-send-email-divanorama@gmail.com>
Heya,
On Thu, Sep 22, 2011 at 21:47, Dmitry Ivankov <divanorama@gmail.com> wrote:
> 'reset' command makes fast-import start a branch from scratch. It's name
> is kept in lookup table but it's sha1 is null_sha1 (special value).
> 'tag' command can be used to tag a branch by it's name. lookup_branch()
> is used it that case and it doesn't check for null_sha1. So fast-import
> writes a tag for null_sha1 object instead of giving a error.
>
> Add a check to deny tagging an empty branch and add a corresponding test.
Makes sense to me.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 5/6] request-pull: state what commit to expect
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
The message gives a detailed explanation of the commit the requester based
the changes on, but lacks information that is necessary for the person who
performs a fetch & merge in order to verify that the correct branch was
fetched when responding to the pull request.
Add a few more lines to describe the commit at the tip expected to be
fetched to the same level of detail as the base commit.
Also update the warning message slightly when the script notices that the
commit may not have been pushed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 34 +++++++++++++++++++---------------
t/t5150-request-pull.sh | 6 ++++++
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index afb75e8..438e7eb 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,7 +35,7 @@ do
shift
done
-base=$1 url=$2 head=${3-HEAD}
+base=$1 url=$2 head=${3-HEAD} status=0
test -n "$base" && test -n "$url" || usage
baserev=$(git rev-parse --verify "$base"^0) &&
@@ -51,25 +51,29 @@ find_matching_branch="/^$headrev "'refs\/heads\//{
}'
branch=$(git ls-remote "$url" | sed -n -e "$find_matching_branch")
url=$(git ls-remote --get-url "$url")
-if test -z "$branch"
-then
- echo "warn: No branch of $url is at:" >&2
- git log --max-count=1 --pretty='tformat:warn: %h: %s' $headrev >&2
- echo "warn: Are you sure you pushed $head there?" >&2
- echo >&2
- echo >&2
- branch=..BRANCH.NOT.VERIFIED..
- status=1
-fi
git show -s --format='The following changes since commit %H:
%s (%ci)
-are available in the git repository at:' $baserev &&
-echo " $url $branch" &&
-echo &&
+are available in the git repository at:
+' $baserev &&
+echo " $url${branch+ $branch}" &&
+git show -s --format='
+for you to fetch changes up to %H:
+
+ %s (%ci)
+
+----------------------------------------------------------------' $headrev &&
git shortlog ^$baserev $headrev &&
-git diff -M --stat --summary $patch $merge_base..$headrev || exit
+git diff -M --stat --summary $patch $merge_base..$headrev || status=1
+
+if test -z "$branch"
+then
+ echo "warn: No branch of $url is at:" >&2
+ git show -s --format='warn: %h: %s' $headrev >&2
+ echo "warn: Are you sure you pushed '$head' there?" >&2
+ status=1
+fi
exit $status
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 9cc0a42..5bd1682 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -193,8 +193,14 @@ test_expect_success 'pull request format' '
SUBJECT (DATE)
are available in the git repository at:
+
URL BRANCH
+ for you to fetch changes up to OBJECT_NAME:
+
+ SUBJECT (DATE)
+
+ ----------------------------------------------------------------
SHORTLOG
DIFFSTAT
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 6/6] request-pull: use the branch description
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
Now we have branch descriptions stored in the repository, we can
use it when preparing the request-pull message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 438e7eb..626cf25 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,7 +35,18 @@ do
shift
done
-base=$1 url=$2 head=${3-HEAD} status=0
+base=$1 url=$2 head=${3-HEAD} status=0 branch_name=
+
+headref=$(git symbolic-ref -q "$head")
+if git show-ref -q --verify "$headref"
+then
+ branch_name=${headref#refs/heads/}
+ if test "z$branch_name" = "z$headref" ||
+ ! git config "branch.$branch_name.description" >/dev/null
+ then
+ branch_name=
+ fi
+fi
test -n "$base" && test -n "$url" || usage
baserev=$(git rev-parse --verify "$base"^0) &&
@@ -66,6 +77,13 @@ for you to fetch changes up to %H:
----------------------------------------------------------------' $headrev &&
+if test -n "$branch_name"
+then
+ echo "(from the branch description for $branch local branch)"
+ echo
+ git config "branch.$branch_name.description"
+ echo "----------------------------------------------------------------"
+fi &&
git shortlog ^$baserev $headrev &&
git diff -M --stat --summary $patch $merge_base..$headrev || status=1
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 4/6] request-pull: modernize style
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
Make it a bit more conforming to Documentation/Codingstyle
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 29 +++++++++++++----------------
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index fc080cc..afb75e8 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,27 +35,24 @@ do
shift
done
-base=$1
-url=$2
-head=${3-HEAD}
+base=$1 url=$2 head=${3-HEAD}
-[ "$base" ] || usage
-[ "$url" ] || usage
+test -n "$base" && test -n "$url" || usage
+baserev=$(git rev-parse --verify "$base"^0) &&
+headrev=$(git rev-parse --verify "$head"^0) || exit
-baserev=`git rev-parse --verify "$base"^0` &&
-headrev=`git rev-parse --verify "$head"^0` || exit
-
-merge_base=`git merge-base $baserev $headrev` ||
+merge_base=$(git merge-base $baserev $headrev) ||
die "fatal: No commits in common between $base and $head"
-branch=$(git ls-remote "$url" \
- | sed -n -e "/^$headrev refs.heads./{
- s/^.* refs.heads.//
- p
- q
- }")
+find_matching_branch="/^$headrev "'refs\/heads\//{
+ s/^.* refs\/heads\///
+ p
+ q
+}'
+branch=$(git ls-remote "$url" | sed -n -e "$find_matching_branch")
url=$(git ls-remote --get-url "$url")
-if [ -z "$branch" ]; then
+if test -z "$branch"
+then
echo "warn: No branch of $url is at:" >&2
git log --max-count=1 --pretty='tformat:warn: %h: %s' $headrev >&2
echo "warn: Are you sure you pushed $head there?" >&2
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 3/6] branch: teach --edit-description option
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
Using branch.$name.description as the configuration key, give users a
place to write about what the purpose of the branch is and things like
that, so that various subsystems, e.g. "push -s", "request-pull", and
"format-patch --cover-letter", can later be taught to use this
information.
The "-m" option similar to "commit/tag" is deliberately omitted, as the
whole point of branch description is about giving descriptive information
(the name of the branch itself is a better place for information that fits
on a single-line).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-branch.txt | 5 +++
builtin/branch.c | 56 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 507b8d0..8871a4e 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -14,6 +14,7 @@ SYNOPSIS
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
+'git branch' --edit-description [<branchname>]
DESCRIPTION
-----------
@@ -144,6 +145,10 @@ start-point is either a local or remote-tracking branch.
like '--track' would when creating the branch, except that where
branch points to is not changed.
+--edit-description::
+ Open an editor and edit the text to explain what the branch is
+ for, to be used by various other commands (e.g. `request-pull`).
+
--contains <commit>::
Only list branches which contain the specified commit.
diff --git a/builtin/branch.c b/builtin/branch.c
index f49596f..fffa319 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -606,11 +606,49 @@ static int opt_parse_merge_filter(const struct option *opt, const char *arg, int
return 0;
}
+static const char edit_description[] = "BRANCH_DESCRIPTION";
+
+static int edit_branch_description(const char *branch_name)
+{
+ FILE *fp;
+ int status;
+ struct strbuf buf = STRBUF_INIT;
+ struct strbuf name = STRBUF_INIT;
+
+ read_branch_desc(&buf, branch_name);
+ if (!buf.len || buf.buf[buf.len-1] != '\n')
+ strbuf_addch(&buf, '\n');
+ strbuf_addf(&buf,
+ "# Please edit the description for the branch\n"
+ "# %s\n"
+ "# Lines starting with '#' will be stripped.\n",
+ branch_name);
+ fp = fopen(git_path(edit_description), "w");
+ if ((fwrite(buf.buf, 1, buf.len, fp) < buf.len) || fclose(fp)) {
+ strbuf_release(&buf);
+ return error(_("could not write branch description template: %s\n"),
+ strerror(errno));
+ }
+ strbuf_reset(&buf);
+ if (launch_editor(git_path(edit_description), &buf, NULL)) {
+ strbuf_release(&buf);
+ return -1;
+ }
+ stripspace(&buf, 1);
+
+ strbuf_addf(&name, "branch.%s.description", branch_name);
+ status = git_config_set(name.buf, buf.buf);
+ strbuf_release(&name);
+ strbuf_release(&buf);
+
+ return status;
+}
+
int cmd_branch(int argc, const char **argv, const char *prefix)
{
int delete = 0, rename = 0, force_create = 0;
int verbose = 0, abbrev = -1, detached = 0;
- int reflog = 0;
+ int reflog = 0, edit_description = 0;
enum branch_track track;
int kinds = REF_LOCAL_BRANCH;
struct commit_list *with_commit = NULL;
@@ -648,6 +686,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
OPT_BOOLEAN('l', NULL, &reflog, "create the branch's reflog"),
+ OPT_BOOLEAN(0, "edit-description", &edit_description,
+ "edit the description for the branch"),
OPT__FORCE(&force_create, "force creation (when already exists)"),
{
OPTION_CALLBACK, 0, "no-merged", &merge_filter_ref,
@@ -694,7 +734,19 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
- else if (argc == 0)
+ else if (edit_description) {
+ const char *branch_name;
+ if (detached)
+ die("Cannot give description to detached HEAD");
+ if (!argc)
+ branch_name = head;
+ else if (argc == 1)
+ branch_name = argv[0];
+ else
+ usage_with_options(builtin_branch_usage, options);
+ if (edit_branch_description(branch_name))
+ return 1;
+ } else if (argc == 0)
return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 2/6] format-patch: use branch description in cover letter
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
Use the description for the branch when preparing the cover letter
when available.
While at it, mark a loosely written codepath that would do a random and
useless thing given an unusual input (e.g. "^master HEAD HEAD^"), which
we may want to fix someday.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
branch.c | 2 +-
builtin/log.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/branch.c b/branch.c
index 88da275..50088a4 100644
--- a/branch.c
+++ b/branch.c
@@ -156,7 +156,7 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)
strbuf_addf(&name, "branch.%s.description", branch_name);
cb.config_name = name.buf;
cb.value = NULL;
- if (git_config(read_branch_desc_cb, &cb)) {
+ if (git_config(read_branch_desc_cb, &cb) < 0) {
strbuf_release(&name);
return -1;
}
diff --git a/builtin/log.c b/builtin/log.c
index f5d4930..e80a925 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -19,6 +19,7 @@
#include "remote.h"
#include "string-list.h"
#include "parse-options.h"
+#include "branch.h"
/* Set a default date-time format for git log ("log.date" config variable) */
static const char *default_date_mode = NULL;
@@ -746,10 +747,24 @@ static void print_signature(void)
printf("-- \n%s\n\n", signature);
}
+static void add_branch_description(struct strbuf *buf, const char *branch_name)
+{
+ struct strbuf desc = STRBUF_INIT;
+ if (!branch_name || !*branch_name)
+ return;
+ read_branch_desc(&desc, branch_name);
+ if (desc.len) {
+ strbuf_addch(buf, '\n');
+ strbuf_add(buf, desc.buf, desc.len);
+ strbuf_addch(buf, '\n');
+ }
+}
+
static void make_cover_letter(struct rev_info *rev, int use_stdout,
int numbered, int numbered_files,
struct commit *origin,
int nr, struct commit **list, struct commit *head,
+ const char *branch_name,
int quiet)
{
const char *committer;
@@ -807,6 +822,7 @@ static void make_cover_letter(struct rev_info *rev, int use_stdout,
pp_user_info(&pp, NULL, &sb, committer, encoding);
pp_title_line(&pp, &msg, &sb, encoding, need_8bit_cte);
pp_remainder(&pp, &msg, &sb, 0);
+ add_branch_description(&sb, branch_name);
printf("%s\n", sb.buf);
strbuf_release(&sb);
@@ -1006,6 +1022,35 @@ static int cc_callback(const struct option *opt, const char *arg, int unset)
return 0;
}
+static char *find_branch_name(struct rev_info *rev)
+{
+ int i, positive = -1;
+ unsigned char branch_sha1[20];
+ struct strbuf buf = STRBUF_INIT;
+ const char *branch;
+
+ for (i = 0; i < rev->cmdline.nr; i++) {
+ if (rev->cmdline.rev[i].flags & UNINTERESTING)
+ continue;
+ if (positive < 0)
+ positive = i;
+ else
+ return NULL;
+ }
+ if (positive < 0)
+ return NULL;
+ strbuf_addf(&buf, "refs/heads/%s", rev->cmdline.rev[positive].name);
+ branch = resolve_ref(buf.buf, branch_sha1, 1, 0);
+ if (!branch ||
+ prefixcmp(branch, "refs/heads/") ||
+ hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
+ branch = NULL;
+ strbuf_release(&buf);
+ if (branch)
+ return xstrdup(rev->cmdline.rev[positive].name);
+ return NULL;
+}
+
int cmd_format_patch(int argc, const char **argv, const char *prefix)
{
struct commit *commit;
@@ -1027,6 +1072,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
struct strbuf buf = STRBUF_INIT;
int use_patch_format = 0;
int quiet = 0;
+ char *branch_name = NULL;
const struct option builtin_format_patch_options[] = {
{ OPTION_CALLBACK, 'n', "numbered", &numbered, NULL,
"use [PATCH n/m] even with a single patch",
@@ -1217,8 +1263,16 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
* origin" that prepares what the origin side still
* does not have.
*/
+ unsigned char sha1[20];
+ const char *ref;
+
rev.pending.objects[0].item->flags |= UNINTERESTING;
add_head_to_pending(&rev);
+ ref = resolve_ref("HEAD", sha1, 1, NULL);
+ if (ref && !prefixcmp(ref, "refs/heads/"))
+ branch_name = xstrdup(ref + strlen("refs/heads/"));
+ else
+ branch_name = xstrdup(""); /* no branch */
}
/*
* Otherwise, it is "format-patch -22 HEAD", and/or
@@ -1234,16 +1288,26 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.show_root_diff = 1;
if (cover_letter) {
- /* remember the range */
+ /*
+ * NEEDSWORK:randomly pick one positive commit to show
+ * diffstat; this is often the tip and the command
+ * happens to do the right thing in most cases, but a
+ * complex command like "--cover-letter a b c ^bottom"
+ * picks "c" and shows diffstat between bottom..c
+ * which may not match what the series represents at
+ * all and totally broken.
+ */
int i;
for (i = 0; i < rev.pending.nr; i++) {
struct object *o = rev.pending.objects[i].item;
if (!(o->flags & UNINTERESTING))
head = (struct commit *)o;
}
- /* We can't generate a cover letter without any patches */
+ /* There is nothing to show; it is not an error, though. */
if (!head)
return 0;
+ if (!branch_name)
+ branch_name = find_branch_name(&rev);
}
if (ignore_if_in_upstream) {
@@ -1294,7 +1358,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
if (thread)
gen_message_id(&rev, "cover");
make_cover_letter(&rev, use_stdout, numbered, numbered_files,
- origin, nr, list, head, quiet);
+ origin, nr, list, head, branch_name, quiet);
total++;
start_number--;
}
@@ -1366,6 +1430,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
fclose(stdout);
}
free(list);
+ free(branch_name);
string_list_clear(&extra_to, 0);
string_list_clear(&extra_cc, 0);
string_list_clear(&extra_hdr, 0);
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 1/6] branch: add read_branch_desc() helper function
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
This will be used by various callers that make use of the branch
description throughout the system, so that if we need to update
the implementation the callers do not have to be modified.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
branch.c | 31 +++++++++++++++++++++++++++++++
branch.h | 5 +++++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/branch.c b/branch.c
index fecedd3..88da275 100644
--- a/branch.c
+++ b/branch.c
@@ -135,6 +135,37 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
return 0;
}
+struct branch_desc_cb {
+ const char *config_name;
+ const char *value;
+};
+
+static int read_branch_desc_cb(const char *var, const char *value, void *cb)
+{
+ struct branch_desc_cb *desc = cb;
+ if (strcmp(desc->config_name, var))
+ return 0;
+ free((char *)desc->value);
+ return git_config_string(&desc->value, var, value);
+}
+
+int read_branch_desc(struct strbuf *buf, const char *branch_name)
+{
+ struct branch_desc_cb cb;
+ struct strbuf name = STRBUF_INIT;
+ strbuf_addf(&name, "branch.%s.description", branch_name);
+ cb.config_name = name.buf;
+ cb.value = NULL;
+ if (git_config(read_branch_desc_cb, &cb)) {
+ strbuf_release(&name);
+ return -1;
+ }
+ if (cb.value)
+ strbuf_addstr(buf, cb.value);
+ strbuf_release(&name);
+ return 0;
+}
+
int validate_new_branchname(const char *name, struct strbuf *ref,
int force, int attr_only)
{
diff --git a/branch.h b/branch.h
index 1285158..1493f73 100644
--- a/branch.h
+++ b/branch.h
@@ -46,4 +46,9 @@ void remove_branch_state(void);
#define BRANCH_CONFIG_VERBOSE 01
extern void install_branch_config(int flag, const char *local, const char *origin, const char *remote);
+/*
+ * Read branch description
+ */
+extern int read_branch_desc(struct strbuf *, const char *branch_name);
+
#endif
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox