* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 14:00 UTC (permalink / raw)
To: Mikael Magnusson
Cc: Santi Béjar, Wincent Colaiuta, Shawn O. Pearce,
Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git
In-Reply-To: <237967ef0903200553v58af40b5sfbfa0bbb1f9d96eb@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1920 bytes --]
Hi,
On Fri, 20 Mar 2009, Mikael Magnusson wrote:
> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 20 Mar 2009, Santi Béjar wrote:
> >
> >> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >>
> >> > On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
> >> >
> >> >> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
> >> >>
> >> >> >Often, it is quite interesting to inspect the branch tracked by a
> >> >> >given branch. This patch introduces a nice notation to get at the
> >> >> >tracked branch: 'BEL<branch>' can be used to access that tracked
> >> >> >branch.
> >> >> >
> >> >> >A special shortcut 'BEL' refers to the branch tracked by the current
> >> >> >branch.
> >> >> >
> >> >> >Suggested by Pasky and Shawn.
> >> >>
> >> >> What does BEL actually stand for? I read Shawn's suggestion, but it's
> >> >> not immediately clear to me what "BEL" means.
> >> >
> >> > It is the ASCII "bell" character, 007 (I always wanted to write that
> >> > magic identifier into a patch).
> >> >
> >> > FWIW you could type it in a regular ANSI terminal using Control-v
> >> > Control-g.
> >>
> >> Can we use branch^{origin} instead? It is longer to type, but uses the
> >> same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to know
> >> how to produce the bell character.
> >
> > I think I addressed that issue already. (Summary: I do not like it)
> >
> > Let me spell it out if it was not obvious yet: the BEL patch was meant as
> > a more or less funny reminder that the issue is not solved and that I need
> > help.
>
> Would :%:foo work? I thought about the reserved prefix :/! , but :/!!
> isn't reserved so I don't think that would work. And it's pretty
> annoying to type too.
Or maybe :%foo?
That would have a rather nasty interaction with code I have in my tree to
refer to the cache-trees via ':<path>', but I guess I can live with that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Document and test the new % shotcut for the tracked branch
From: Michael J Gruber @ 2009-03-20 14:15 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Michael J Gruber, git, Shawn O. Pearce, Petr Baudis,
Andreas Gruenbacher, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903201128380.10279@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 20.03.2009 11:31:
> Hi,
>
> On Fri, 20 Mar 2009, Michael J Gruber wrote:
>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>
> That is brutal. First shot, then cut.
Oh my gosh, noooow I got it! Better late than never. You really have a
thing with typos... Although not quoting the subject was not fair ;)
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) with posix semantics
From: Alex Riesen @ 2009-03-20 14:17 UTC (permalink / raw)
To: Rogan Dawes
Cc: Johannes Schindelin, Git Mailing List, Johannes Sixt, Jeff King,
layer, Junio C Hamano
In-Reply-To: <49C39EFE.8040507@dawes.za.net>
2009/3/20 Rogan Dawes <lists@dawes.za.net>:
> Alex Riesen wrote:
>> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>> On Fri, 20 Mar 2009, Alex Riesen wrote:
>>>
>>>> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>>>> Now, we _do_ have msysGit, you _do_ have shown the capability to fix
>>>>> issues when they arise, so I do _not_ see any obstacle why you should
>>>>> not go msysGit, rather than staying with the pain of trying to stay
>>>>> POSIX-compatible, but not quite all the time.
>>>> I understand. It is not pure POSIX compatibility I seek. I just can't
>>>> use MinGW port, because I absolutely must use the cygwin environment
>>>> (for "hysterical" reasons) and they don't play well together (tried,
>>>> yes. Conflicting libraries, but you already know that).
>>> Maybe we can work on those conflicting libraries? After all, we do have a
>>> "rebase.exe" tool now (for all those as puzzled by the naming as I was:
>>> the rebase.exe tool can shift the memory range used by a .dll so that it
>>> does not overlap with that one of another .dll).
>>
>> As long as they can be made to coexist I'm fine. Wasn't the problem
>> that MinGW/MSYS used cygwin1.dll if it were in PATH? Or was it
>> something else with their supporting libraries?
>>
>> My other problem is that the cygwin programs, and the worst of all - a
>> proprietary compiler based on cygwin, must be in PATH. AFAIR, the
>> presence of cygwin in PATH broken shell scripting.
>
> How about a wrapper that fixes the PATH before exec'ing git? i.e.
> removes cygwin and the compiler.
>
For shame... I never tried :-/
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) with posix semantics
From: Alex Riesen @ 2009-03-20 14:20 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Johannes Sixt, Jeff King, layer, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903201446590.6865@intel-tinevez-2-302>
2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Fri, 20 Mar 2009, Alex Riesen wrote:
> (Unfortunately, a few important parts of Git are still implemented as
> shell scripts: bisect, pull and rebase being the most obvious to me, but
> repack, stash and submodule are not too unimportant, either.)
I can't imagine not using bisect or rebase.
>> My other problem is that the cygwin programs, and the worst of all - a
>> proprietary compiler based on cygwin, must be in PATH. AFAIR, the
>> presence of cygwin in PATH broken shell scripting.
>
> If it is a PATH issue, then it should be fixable by teaching msysGit to
> prepend $GIT_ROOT/bin and $GIT_ROOT/libexec/git-core to the PATH, but
> AFAIR we already do that.
>
> *clicketyclick*
>
> Yep, from reading setup_path() in exec_cmd.c, it appears that we prepend
> the PATH correctly.
>
> Traditionally, we did have problems with Cygwin, that is correct, but I
> think with your help we can resolve the interaction issues.
Ok. I guess it is a time for me to take another look at mingw port.
^ permalink raw reply
* Tracking of local branches
From: Michael J Gruber @ 2009-03-20 14:22 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Johannes Schindelin
Hi there,
me again. In connection with Dscho's recent patch which rang the bell on
tracked branches I noticed that local branches are treated somewhat
inconsistently by git. There are 2 ways to fix it, and I ask you for
your input on which one to choose.
First of all:
The documentation seems to imply that it's okay to follow local
branches, i.e. to have tracked local branches. Specifically, the option
--track allows setting up tracking info (branch.foo.merge) in cases
where it's not set up automatically (it is when you branch off a remote
tracking branch).
If it's not OK to say "git checkout -b newbranch --track local" when
local is a local branch you can stop reading here and tell me to stop
writing...
Now, assuming it's okay to have a local branch being tracked, the
current situation is:
git fetch/pull is okay (respects the setting)
git status/checkout/rev-parse BEL is not (acts as if there is no
tracking info)
I think I have tracked it down (pun intended) to the fact that one sort
of commands looks at the struct member branch->merge, the other at
branch->merge_name. The latter is set for branches which follow
something, the former only for followers of remote branches.
I semi-successfully messed around in remote.c (format_tracking_info(),
stat_tracking_info()) to make it use branch->merge_name rather than
branch->merge. This makes "git status" work as expected ("Your branch
is... severely screwed.") for tracked local branches. (It's messed up
for remote ones but hey it was a first shot; merge[0]->dst is really
needed here I guess.)
Now I could go after sha1_name.c and do the same,
OR
make it so that all branches have their merge member set up, uhm. Any
possible side effects?
What do you think?
Michael
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Michael J Gruber @ 2009-03-20 14:31 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Petr Baudis, Junio C Hamano, Jeff King, Shawn O. Pearce,
Andreas Gruenbacher, git
In-Reply-To: <alpine.DEB.1.00.0903201255230.6865@intel-tinevez-2-302>
Johannes Schindelin venit, vidit, dixit 20.03.2009 12:57:
> Hi,
>
> On Fri, 20 Mar 2009, Petr Baudis wrote:
>
>> On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:
>>
>>> On Fri, 20 Mar 2009, Petr Baudis wrote:
>>>
>>>> On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
>>>>> On Thu, 19 Mar 2009, Junio C Hamano wrote:
>>>>>
>>>>>> I think you are right. It is just "git branch" and perhaps "git
>>>>>> update-ref" are too loose in enforcing what can be created.
>>>>>
>>>>> "git branch" I agree with, but not "git update-ref". As plumbing, the
>>>>> latter should be much more allowing, feeding rope aplenty (but also
>>>>> allowing cool tricks we do not think about yet).
>>>>
>>>> We shouldn't allow creating insane ref names even with update-ref. That
>>>> way porcelains cannot rely on update-ref to sanity check the user's
>>>> crap. At most, maybe you might want to bypass this check with some force
>>>> switch, though I really can't quite imagine why.
>>>
>>> You really cannot imagine? You, the author of filter-branch? People _do_
>>> have fscked-up repositories, but they get really angry when they cannot
>>> use rebase or filter-branch on them.
>>
>> They can rename the ref as the first step of a cleanup, can't they?
>
> Well, of course, we can make life hard on everybody. That is quite
> possible.
>
> But then, we can be nice, and at the same time fix the problem _properly_.
>
> IMHO a _warning_ should be the best thing.
>
> But all this does not solve _my_ problem: I'd like something as easy to
> write as %next, but as unlikely to be used in existing refs as @{..}.
Do we have ^ as a prefix yet?
Neither the suffix (commit^) nor the infix (commit^{type}) allow an
empty commit (for HEAD) - which might be nice, though. So, ^ as a prefix
is free, even without any specifier after.
Also, I don't think people would use @@ much in branch names.
Michael
^ permalink raw reply
* Re: [PATCH] import-tars: separate author from committer
From: Shawn O. Pearce @ 2009-03-20 14:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1237543070-4909-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> The import-tars script is typically employed to (re)create the past
> history of a project from stored tars. Although assigning authorship in
> these cases can be a somewhat arbitrary process, it makes sense to set
> the author to whoever created the tars in the first place (if it's
> known), and (s)he can in general be different from the committer
> (whoever is running the script).
>
> Implement this by having separate author and committer data, making them
> settable from the usual GIT_* environment variables.
> ---
>
> Or should I have made the ENV access a separate patch?
Looks fine to me.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: some French translation enhancements
From: Alexandre Bourget @ 2009-03-20 14:34 UTC (permalink / raw)
To: Mike Hommey; +Cc: Nicolas Sebrecht, Git List, Sam Hocevar, Christian Couder
In-Reply-To: <20090320071316.GB5693@glandium.org>
Le vendredi 20 mars 2009 à 08:13 +0100, Mike Hommey a écrit :
> On Fri, Mar 20, 2009 at 01:54:02AM +0100, Nicolas Sebrecht wrote:
> IMHO, we should find a better way to say that than to use the "index"
> word at all. This obviously applies to all uses of "index" in french
> where we avoided it in english.
>
> OTOH, the best I can find for "staging area" is "zone de préparation",
> and that doesn't help finding a word for stage and unstage.
"zone de préparation" sounds good to me.
-------------
> [from another e-mail]
> > We should care that the revert operation does *not* remove a commit but
> > add a new one (this makes sense to Git). As a consequence, we should
> > avoid "Annuler", "Révoquer" and "Défaire".
> >
> > "Inverser" looks like the best translation.
> Yeah, I agree with that reasoning.
Hmm.. if you look at the git-gui program, when we use "Revert", it's not
always the usage of the git-revert command that is invoked.
Most of the time, it's the equivalent of running "git reset --hard", or
"git checkout path/filename.ext" (in fact, it uses git-checkout-index,
see git-gui/lib/index.tcl::revert_helper..).
That is true for example in the "Commit" menu, 3rd to last item, which
reads in french "Inverser les modifications" or "Révoker les
modifications" as I modified it at some point.
What happens here, is really not inversion of modifications; we're just
wiping out all changes from the working dir, back to HEAD. Several of
the translated messages are used in *that* context.
So, considering this, which one of: "Annuler", "Révoquer", "Défaire",
"Effacer", "Restaurer l'original", "Scrapper", "Trucider", "Supprimer" +
"les modifications" would be best ?
It should be obvious that it's going to affect the blue icons, and that
those modifications will dissapear forever.
Also note that "svn revert" does like git-checkout-index, and not like
git-revert, so the terms must be clear here, even in English.
Alexandre
--
Alexandre Bourget
Directeur adjoint au développement
Consultant en Logiciel Libre
Savoir-faire Linux Inc.
alexandre.bourget@savoirfairelinux.com
514-276-5468 poste 124
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 15:01 UTC (permalink / raw)
To: Michael J Gruber
Cc: Petr Baudis, Junio C Hamano, Jeff King, Shawn O. Pearce,
Andreas Gruenbacher, git
In-Reply-To: <49C3A8D7.1040509@drmicha.warpmail.net>
Hi,
On Fri, 20 Mar 2009, Michael J Gruber wrote:
> Do we have ^ as a prefix yet?
Yes, it means "not". IOW '^bla blub' is the same as 'bla..blub'.
> Also, I don't think people would use @@ much in branch names.
Whoa...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: some French translation enhancements
From: Shawn O. Pearce @ 2009-03-20 15:03 UTC (permalink / raw)
To: Christian Couder
Cc: Git List, Sam Hocevar, Alexandre Bourget, Nicolas Sebrecht
In-Reply-To: <200903200841.02052.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> wrote:
> Le vendredi 20 mars 2009, Nicolas Sebrecht a ?crit :
> > Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
> > ---
> > po/fr.po | 21 ++++++++++-----------
> > 1 files changed, 10 insertions(+), 11 deletions(-)
>
> Acked-by: Christian Couder <chriscool@tuxfamily.org>
>
> Shawn,
>
> Could you add Sam's patch and this one on top of Sam's patch?
>
> Could you also squash the following change:
>
> s/Essayez de r?cup?r?/Essayez de r?cup?rer/
>
> If you prefer me to send yet another patch for this last change, please tell
> me.
It would really help me if translation patches didn't require me
to hand-edit them. My email client mangles them bad enough as
it is, and I can only read English, so its very likely I'd wind
up mangling a translation of "revert" into "your cow ate my pig,
please give me your truck as payment".
--
Shawn.
^ permalink raw reply
* [JGIT PATCH] Split refspecs on the last : not the first
From: Shawn O. Pearce @ 2009-03-20 15:12 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Recent discussion about a potential ':%branchname' syntax for
remote branches led rise to the question on #git of whether or
not this could be used on the lhs of a push refspec, such as
"+:%master:master".
Testing shows git-core permits this, as it must be splitting the
refspec with strrchr(), splitting along the last : in the string.
Make JGit match the split semantics.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/jgit/transport/RefSpecTestCase.java | 12 ++++++++++++
.../src/org/spearce/jgit/transport/RefSpec.java | 2 +-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/RefSpecTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/RefSpecTestCase.java
index 11e7cdb..2f7214c 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/RefSpecTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/RefSpecTestCase.java
@@ -63,6 +63,18 @@ public void testMasterMaster() {
assertFalse(rs.matchDestination(r));
}
+ public void testSplitLastColon() {
+ final String lhs = ":m:a:i:n:t";
+ final String rhs = "refs/heads/maint";
+ final RefSpec rs = new RefSpec(lhs + ":" + rhs);
+ assertFalse(rs.isForceUpdate());
+ assertFalse(rs.isWildcard());
+ assertEquals(lhs, rs.getSource());
+ assertEquals(rhs, rs.getDestination());
+ assertEquals(lhs + ":" + rhs, rs.toString());
+ assertEquals(rs, new RefSpec(rs.toString()));
+ }
+
public void testForceMasterMaster() {
final String sn = "refs/heads/master";
final RefSpec rs = new RefSpec("+" + sn + ":" + sn);
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/RefSpec.java b/org.spearce.jgit/src/org/spearce/jgit/transport/RefSpec.java
index e75b272..273aacc 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/RefSpec.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/RefSpec.java
@@ -115,7 +115,7 @@ public RefSpec(final String spec) {
s = s.substring(1);
}
- final int c = s.indexOf(':');
+ final int c = s.lastIndexOf(':');
if (c == 0) {
s = s.substring(1);
if (isWildcard(s))
--
1.6.2.1.352.gae594
^ permalink raw reply related
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Michael J Gruber @ 2009-03-20 15:12 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Petr Baudis, Junio C Hamano, Jeff King, Shawn O. Pearce,
Andreas Gruenbacher, git
In-Reply-To: <alpine.DEB.1.00.0903201600500.6865@intel-tinevez-2-302>
Johannes Schindelin venit, vidit, dixit 20.03.2009 16:01:
> Hi,
>
> On Fri, 20 Mar 2009, Michael J Gruber wrote:
>
>> Do we have ^ as a prefix yet?
>
> Yes, it means "not". IOW '^bla blub' is the same as 'bla..blub'.
Oh yes, I forgot. commit specifiers and ranges are in different sections
in git-rev-parse.1.
>> Also, I don't think people would use @@ much in branch names.
>
> Whoa...
We already have ^! and ^@ (I didn't know).
While someone may have a branch like "@junio" I think doubled special
characters are uncommon. Except for that topic branch /&$%$%§$%&/) for a
really nasty bug.
Of course, if @@ refers to a tracked branch which follows another
branch, then @@@@...
Michael
^ permalink raw reply
* Re: [PATCH] Documentation/git-filter-branch.txt: Remove unnecessary URL quoting
From: Thomas Rast @ 2009-03-20 15:19 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git
In-Reply-To: <200903200012.10454.johan@herland.net>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
Johan Herland wrote:
> Embedding the URL in '+++' causes AsciiDoc (v8.4.1) to generate invalid XML.
> None of the other URLs in Git's documentation are quoted in this manner.
> There's no reason to treat this URL differently.
>
> Signed-off-by: Johan Herland <johan@herland.net>
[...]
> -* Clone it with `git clone +++file:///path/to/repo+++`. The clone
> +* Clone it with `git clone file:///path/to/repo`. The clone
I deliberately wrote it that way because *not* quoting it, at least on
my box, formats the entire paragraph in monospace. Apparently it
treats the ` as part of an autodetected URL or some such. This is
independent of my choice of ASCIIDOC8 or DOCBOOK_XSL_172 settings. Am
I missing another flag that avoids this problem?
I have these packages installed from opensuse:
asciidoc-8.2.7-29.10
docbook_4-4.5-111.8
docbook-xsl-stylesheets-1.74.0-1.35
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Tracking of local branches
From: Michael J Gruber @ 2009-03-20 16:13 UTC (permalink / raw)
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin
In-Reply-To: <49C3A6AE.7020104@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 20.03.2009 15:22:
> Hi there,
>
> me again. In connection with Dscho's recent patch which rang the bell on
> tracked branches I noticed that local branches are treated somewhat
> inconsistently by git. There are 2 ways to fix it, and I ask you for
> your input on which one to choose.
>
> First of all:
> The documentation seems to imply that it's okay to follow local
> branches, i.e. to have tracked local branches. Specifically, the option
> --track allows setting up tracking info (branch.foo.merge) in cases
> where it's not set up automatically (it is when you branch off a remote
> tracking branch).
>
> If it's not OK to say "git checkout -b newbranch --track local" when
> local is a local branch you can stop reading here and tell me to stop
> writing...
>
> Now, assuming it's okay to have a local branch being tracked, the
> current situation is:
>
> git fetch/pull is okay (respects the setting)
> git status/checkout/rev-parse BEL is not (acts as if there is no
> tracking info)
>
> I think I have tracked it down (pun intended) to the fact that one sort
> of commands looks at the struct member branch->merge, the other at
> branch->merge_name. The latter is set for branches which follow
> something, the former only for followers of remote branches.
>
> I semi-successfully messed around in remote.c (format_tracking_info(),
> stat_tracking_info()) to make it use branch->merge_name rather than
> branch->merge. This makes "git status" work as expected ("Your branch
> is... severely screwed.") for tracked local branches. (It's messed up
> for remote ones but hey it was a first shot; merge[0]->dst is really
> needed here I guess.)
>
> Now I could go after sha1_name.c and do the same,
>
> OR
>
> make it so that all branches have their merge member set up, uhm. Any
> possible side effects?
>
> What do you think?
> Michael
OK, I think I got this working with approach 2 above. All existing tests
pass. Now I'll cook up tests which only my new code passes ;) But that
may take a few days.
Michael
^ permalink raw reply
* [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 16:17 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Petr Baudis, Andreas Gruenbacher, B.Steinbrink,
git
In-Reply-To: <alpine.DEB.1.00.0903201027450.10279@pacific.mpi-cbg.de>
Often, it is quite interesting to inspect the branch tracked by a given
branch. This patch introduces a nice notation to get at the tracked
branch: '%<branch>' can be used to access that tracked branch.
A special shortcut '%' refers to the branch tracked by the current branch.
Suggested by Pasky.
Even if a branch name can legally start with a '%' sign, we can use the
special character '%' here, as you can always specify the full ref:
refs/heads/%my-branch (pointed out by doener on IRC).
This patch extends the function introduced to handle the nth-last branch
(via the {-<n>} notation); therefore that function name was renamed to
something more general.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Sometimes IRC is awesome. Knowing that you can always access an
otherwise-hidden branch using the full name, I am now fully
comfortable with '%[<branch>]'.
Documentation/git-rev-parse.txt | 3 ++
sha1_name.c | 21 ++++++++++++---
t/t1506-rev-parse-tracked.sh | 54 +++++++++++++++++++++++++++++++++++++++
3 files changed, 74 insertions(+), 4 deletions(-)
create mode 100755 t/t1506-rev-parse-tracked.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 5ed2bc8..a4bcd5e 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -215,6 +215,9 @@ when you run 'git-merge'.
* The special construct '@\{-<n>\}' means the <n>th branch checked out
before the current one.
+* The prefix '%' to a ref means the branch tracked by that ref. If no
+ ref was specified, it means the branch tracked by the current branch.
+
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'
diff --git a/sha1_name.c b/sha1_name.c
index 2f75179..cb4168d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
#include "blob.h"
#include "tree-walk.h"
#include "refs.h"
+#include "remote.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -240,9 +241,10 @@ static int ambiguous_path(const char *path, int len)
/*
* *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form %<branch>.
*/
-static char *substitute_nth_last_branch(const char **string, int *len)
+static char *substitute_branch(const char **string, int *len)
{
struct strbuf buf = STRBUF_INIT;
int ret = interpret_nth_last_branch(*string, &buf);
@@ -254,12 +256,23 @@ static char *substitute_nth_last_branch(const char **string, int *len)
return (char *)*string;
}
+ if (**string == '%') {
+ struct branch *tracking = branch_get((*string)[1] ?
+ (*string) + 1 : NULL);
+
+ if (tracking->merge && tracking->merge[0]->dst) {
+ *string = xstrdup(tracking->merge[0]->dst);
+ *len = strlen(*string);
+ return (char *)*string;
+ }
+ }
+
return NULL;
}
int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
{
- char *last_branch = substitute_nth_last_branch(&str, &len);
+ char *last_branch = substitute_branch(&str, &len);
const char **p, *r;
int refs_found = 0;
@@ -288,7 +301,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
{
- char *last_branch = substitute_nth_last_branch(&str, &len);
+ char *last_branch = substitute_branch(&str, &len);
const char **p;
int logs_found = 0;
diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
new file mode 100755
index 0000000..359f648
--- /dev/null
+++ b/t/t1506-rev-parse-tracked.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+test_description='test %<branch> syntax'
+
+. ./test-lib.sh
+
+
+test_expect_success 'setup' '
+
+ test_commit 1 &&
+ git checkout -b side &&
+ test_commit 2 &&
+ git checkout master &&
+ git clone . clone &&
+ test_commit 3 &&
+ (cd clone &&
+ test_commit 4 &&
+ git branch --track my-side origin/side)
+
+'
+
+full_name () {
+ (cd clone &&
+ git rev-parse --symbolic-full-name "$@")
+}
+
+commit_subject () {
+ (cd clone &&
+ git show -s --pretty=format:%s "$@")
+}
+
+test_expect_success '% resolves to correct full name' '
+
+ test refs/remotes/origin/master = "$(full_name %)"
+
+'
+
+test_expect_success '%my-side resolves to correct full name' '
+
+ test refs/remotes/origin/side = "$(full_name %my-side)"
+
+'
+
+test_expect_success '%my-side resolves to correct commit' '
+
+ git checkout side &&
+ test_commit 5 &&
+ (cd clone && git fetch) &&
+ test 2 = "$(commit_subject my-side)" &&
+ test 5 = "$(commit_subject %my-side)"
+
+'
+
+test_done
--
1.6.2.1.477.g74567
^ permalink raw reply related
* [StGit PATCH] Add the --merged option to goto
From: Catalin Marinas @ 2009-03-20 16:15 UTC (permalink / raw)
To: git, Karl Hasselström
This patch adds support for checking which patches were already merged
upstream. This checking is done by trying to reverse-apply the patches
in the index before pushing them onto the stack. The trivial merge cases
in Index.merge() are ignored when performing this operation otherwise
the results could be wrong (e.g. a patch adding a hunk and a subsequent
patch canceling the previous change would both be considered merged).
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
This is in preparation for the updating of the push command where we
have this functionality (I think we had it for goto as well but was lost
with the update to stgit.lib). Test cases with --merged are already done
for the push command, so I haven't added any for goto (but I'll push
this patch only after push is updated).
stgit/argparse.py | 4 ++++
stgit/commands/goto.py | 12 +++++++++---
stgit/lib/git.py | 15 ++++++++-------
stgit/lib/transaction.py | 42 +++++++++++++++++++++++++++++++++++-------
4 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/stgit/argparse.py b/stgit/argparse.py
index 85ee6e3..765579c 100644
--- a/stgit/argparse.py
+++ b/stgit/argparse.py
@@ -225,6 +225,10 @@ def keep_option():
short = 'Keep the local changes',
default = config.get('stgit.autokeep') == 'yes')]
+def merged_option():
+ return [opt('-m', '--merged', action = 'store_true',
+ short = 'Check for patches merged upstream')]
+
class CompgenBase(object):
def actions(self, var): return set()
def words(self, var): return set()
diff --git a/stgit/commands/goto.py b/stgit/commands/goto.py
index 66f49df..839b75c 100644
--- a/stgit/commands/goto.py
+++ b/stgit/commands/goto.py
@@ -28,7 +28,7 @@ Push/pop patches to/from the stack until the one given on the command
line becomes current."""
args = [argparse.other_applied_patches, argparse.unapplied_patches]
-options = argparse.keep_option()
+options = argparse.keep_option() + argparse.merged_option()
directory = common.DirectoryHasRepositoryLib()
@@ -47,8 +47,14 @@ def func(parser, options, args):
assert not trans.pop_patches(lambda pn: pn in to_pop)
elif patch in trans.unapplied:
try:
- for pn in trans.unapplied[:trans.unapplied.index(patch)+1]:
- trans.push_patch(pn, iw, allow_interactive = True)
+ to_push = trans.unapplied[:trans.unapplied.index(patch)+1]
+ if options.merged:
+ merged = set(trans.check_merged(to_push))
+ else:
+ merged = set()
+ for pn in to_push:
+ trans.push_patch(pn, iw, allow_interactive = True,
+ already_merged = pn in merged)
except transaction.TransactionHalted:
pass
elif patch in trans.hidden:
diff --git a/stgit/lib/git.py b/stgit/lib/git.py
index e0a3c96..875e352 100644
--- a/stgit/lib/git.py
+++ b/stgit/lib/git.py
@@ -732,7 +732,7 @@ class Index(RunWithEnv):
# to use --binary.
self.apply(self.__repository.diff_tree(tree1, tree2, ['--full-index']),
quiet)
- def merge(self, base, ours, theirs, current = None):
+ def merge(self, base, ours, theirs, current = None, check_trivial = True):
"""Use the index (and only the index) to do a 3-way merge of the
L{Tree}s C{base}, C{ours} and C{theirs}. The merge will either
succeed (in which case the first half of the return value is
@@ -752,12 +752,13 @@ class Index(RunWithEnv):
assert current == None or isinstance(current, Tree)
# Take care of the really trivial cases.
- if base == ours:
- return (theirs, current)
- if base == theirs:
- return (ours, current)
- if ours == theirs:
- return (ours, current)
+ if check_trivial:
+ if base == ours:
+ return (theirs, current)
+ if base == theirs:
+ return (ours, current)
+ if ours == theirs:
+ return (ours, current)
if current == theirs:
# Swap the trees. It doesn't matter since merging is
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index b146648..8cd5e50 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -297,7 +297,8 @@ class StackTransaction(object):
out.info('Deleted %s%s' % (pn, s))
return popped
- def push_patch(self, pn, iw = None, allow_interactive = False):
+ def push_patch(self, pn, iw = None, allow_interactive = False,
+ already_merged = False):
"""Attempt to push the named patch. If this results in conflicts,
halts the transaction. If index+worktree are given, spill any
conflicts to them."""
@@ -305,11 +306,14 @@ class StackTransaction(object):
cd = orig_cd.set_committer(None)
oldparent = cd.parent
cd = cd.set_parent(self.top)
- base = oldparent.data.tree
- ours = cd.parent.data.tree
- theirs = cd.tree
- tree, self.temp_index_tree = self.temp_index.merge(
- base, ours, theirs, self.temp_index_tree)
+ if already_merged:
+ tree = cd.tree
+ else:
+ base = oldparent.data.tree
+ ours = cd.parent.data.tree
+ theirs = cd.tree
+ tree, self.temp_index_tree = self.temp_index.merge(
+ base, ours, theirs, self.temp_index_tree)
s = ''
merge_conflict = False
if not tree:
@@ -341,7 +345,9 @@ class StackTransaction(object):
else:
comm = None
s = ' (unmodified)'
- if not merge_conflict and cd.is_nochange():
+ if already_merged:
+ s = ' (merged)'
+ elif not merge_conflict and cd.is_nochange():
s = ' (empty)'
out.info('Pushed %s%s' % (pn, s))
def update():
@@ -379,3 +385,25 @@ class StackTransaction(object):
assert set(self.unapplied + self.hidden) == set(unapplied + hidden)
self.unapplied = unapplied
self.hidden = hidden
+
+ def check_merged(self, patches):
+ """Return a subset of patches already merged."""
+ merged = []
+ temp_index = self.__stack.repository.temp_index()
+ temp_index_tree = None
+ ours = self.stack.head.data.tree
+
+ for pn in reversed(patches):
+ # check whether patch changes can be reversed in the current tree
+ cd = self.patches[pn].data
+ base = cd.tree
+ theirs = cd.parent.data.tree
+ tree, temp_index_tree = \
+ temp_index.merge(base, ours, theirs, temp_index_tree,
+ check_trivial = False)
+ if tree:
+ merged.append(pn)
+ ours = tree
+
+ temp_index.delete()
+ return merged
^ permalink raw reply related
* Status of GIT for Fedora 10 + gitweb's look
From: Aaron Gray @ 2009-03-20 16:18 UTC (permalink / raw)
To: Git Mailing List
I tried installing Git on F10 and got the following :-
[root@localhost ~]# rpm -Uvh git-1.6.2.1-1.fc9.i386.rpm
error: Failed dependencies:
perl-Git = 1.6.2.1-1.fc9 is needed by git-1.6.2.1-1.fc9.i386
git = 1.6.0.6-3.fc10 is needed by (installed)
perl-Git-1.6.0.6-3.fc10.i386
git = 1.6.0.6-3.fc10 is needed by (installed)
git-svn-1.6.0.6-3.fc10.i386
git = 1.6.0.6-3.fc10 is needed by (installed)
git-daemon-1.6.0.6-3.fc10.i386
git = 1.6.0.6-3.fc10 is needed by (installed)
gitweb-1.6.0.6-3.fc10.i386
Can I install from source I could only find F9 SRPMS.
What I am really after knowing is gitweb on the latest version 1.6.2.1
anything like the nice HTML layout on http://git.kernel.org/ or do I have to
do the html formatting myself in the perl code ?
Many thanks in advance,
Aaron
^ permalink raw reply
* [JGIT PATCH] Ensure RawParseUtils.lineMap last element is the buffer end
From: Shawn O. Pearce @ 2009-03-20 16:38 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Application code is easier to write when we can assume that for
any given source line the last element of the IntList returned
by lineMap contains the value of the end parameter. This makes
it easy to extract any line by saying:
RawParseUtils.decodeNoFallback(
Constants.CHARSET,
buf,
lineMap.get(lineNbr),
lineMap.get(lineNbr + 1));
without needing to worry about bound checks, assuming of course
that lineNbr is already bound-checked within the range of the file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../jgit/util/RawParseUtils_LineMapTest.java | 16 ++++++++++------
.../src/org/spearce/jgit/util/RawParseUtils.java | 4 ++++
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/util/RawParseUtils_LineMapTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/util/RawParseUtils_LineMapTest.java
index 3f562a4..312e3d8 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/util/RawParseUtils_LineMapTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/util/RawParseUtils_LineMapTest.java
@@ -45,44 +45,48 @@
public void testEmpty() {
final IntList map = RawParseUtils.lineMap(new byte[] {}, 0, 0);
assertNotNull(map);
- assertEquals(1, map.size());
+ assertEquals(2, map.size());
assertEquals(Integer.MIN_VALUE, map.get(0));
+ assertEquals(0, map.get(1));
}
public void testOneBlankLine() {
final IntList map = RawParseUtils.lineMap(new byte[] { '\n' }, 0, 1);
- assertEquals(2, map.size());
+ assertEquals(3, map.size());
assertEquals(Integer.MIN_VALUE, map.get(0));
assertEquals(0, map.get(1));
+ assertEquals(1, map.get(2));
}
public void testTwoLineFooBar() throws UnsupportedEncodingException {
final byte[] buf = "foo\nbar\n".getBytes("ISO-8859-1");
final IntList map = RawParseUtils.lineMap(buf, 0, buf.length);
- assertEquals(3, map.size());
+ assertEquals(4, map.size());
assertEquals(Integer.MIN_VALUE, map.get(0));
assertEquals(0, map.get(1));
assertEquals(4, map.get(2));
+ assertEquals(buf.length, map.get(3));
}
public void testTwoLineNoLF() throws UnsupportedEncodingException {
final byte[] buf = "foo\nbar".getBytes("ISO-8859-1");
final IntList map = RawParseUtils.lineMap(buf, 0, buf.length);
- assertEquals(3, map.size());
+ assertEquals(4, map.size());
assertEquals(Integer.MIN_VALUE, map.get(0));
assertEquals(0, map.get(1));
assertEquals(4, map.get(2));
+ assertEquals(buf.length, map.get(3));
}
public void testFourLineBlanks() throws UnsupportedEncodingException {
final byte[] buf = "foo\n\n\nbar\n".getBytes("ISO-8859-1");
final IntList map = RawParseUtils.lineMap(buf, 0, buf.length);
- assertEquals(5, map.size());
+ assertEquals(6, map.size());
assertEquals(Integer.MIN_VALUE, map.get(0));
assertEquals(0, map.get(1));
assertEquals(4, map.get(2));
assertEquals(5, map.get(3));
assertEquals(6, map.get(4));
+ assertEquals(buf.length, map.get(5));
}
-
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
index 0735ce6..79ebe41 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
@@ -329,6 +329,9 @@ public static final int nextLF(final byte[] b, int ptr, final char chrA) {
* Using a 1 indexed list means that line numbers can be directly accessed
* from the list, so <code>list.get(1)</code> (aka get line 1) returns
* <code>ptr</code>.
+ * <p>
+ * The last element (index <code>map.size()-1</code>) always contains
+ * <code>end</code>.
*
* @param buf
* buffer to scan.
@@ -348,6 +351,7 @@ public static final IntList lineMap(final byte[] buf, int ptr, int end) {
map.fillTo(1, Integer.MIN_VALUE);
for (; ptr < end; ptr = nextLF(buf, ptr))
map.add(ptr);
+ map.add(end);
return map;
}
--
1.6.2.1.352.gae594
^ permalink raw reply related
* Re: Tracking of local branches
From: Junio C Hamano @ 2009-03-20 16:46 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List, Johannes Schindelin, Daniel Barkalow
In-Reply-To: <49C3A6AE.7020104@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> I semi-successfully messed around in remote.c (format_tracking_info(),
> stat_tracking_info()) to make it use branch->merge_name rather than
> branch->merge. This makes "git status" work as expected ("Your branch
> is... severely screwed.") for tracked local branches. (It's messed up
> for remote ones but hey it was a first shot; merge[0]->dst is really
> needed here I guess.)
>
> Now I could go after sha1_name.c and do the same,
>
> OR
>
> make it so that all branches have their merge member set up, uhm. Any
> possible side effects?
My gut feeling is that the latter if works should be preferable for
consistency if nothing else.
The "struct branch" hasn't changed ever since it was introduced by cf81834
(Report information on branches from remote.h, 2007-09-10) and Daniel
might know about some corner cases that rely on branch.merge not being set
up for local ones, but honestly, I would think it would be a bug in the
existing code if there were such cases.
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Junio C Hamano @ 2009-03-20 16:47 UTC (permalink / raw)
To: Petr Baudis
Cc: Johannes Schindelin, Jeff King, Shawn O. Pearce,
Andreas Gruenbacher, git
In-Reply-To: <20090320111238.GZ8940@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> "git branch" I agree with, but not "git update-ref". As plumbing, the
>> latter should be much more allowing, feeding rope aplenty (but also
>> allowing cool tricks we do not think about yet).
>
> We shouldn't allow creating insane ref names even with update-ref. That
> way porcelains cannot rely on update-ref to sanity check the user's
> crap. At most, maybe you might want to bypass this check with some force
> switch, though I really can't quite imagine why.
That's all nice and clean in theory, but it was more or less the same
reasoning as what was behind the tightening not to allow anything but
refs/heads pointed by HEAD, but you know what fell out of it. "Insane"
and "crap" are in the eye of the beholder.
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Junio C Hamano @ 2009-03-20 17:03 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink,
git
In-Reply-To: <alpine.DEB.1.00.0903201714020.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Often, it is quite interesting to inspect the branch tracked by a given
> branch. This patch introduces a nice notation to get at the tracked
> branch: '%<branch>' can be used to access that tracked branch.
>
> A special shortcut '%' refers to the branch tracked by the current branch.
>
> Suggested by Pasky.
>
> Even if a branch name can legally start with a '%' sign, we can use the
> special character '%' here, as you can always specify the full ref:
> refs/heads/%my-branch (pointed out by doener on IRC).
That is not a good argument, as %<name> is (just like name@{-n} is) a
substitute way to spell the "name" of a branch, not just a random SHA-1,
and to some commands it makes a difference between <branchname> and
refs/heads/<branchname>. The latter is not giving the name of the branch,
but merely a commit object name.
An most obvious one is that "git checkout branchname" and "git checkout
refs/heads/branchname" behave differently. You cannot checkout a branch
called %master after this patch goes in.
Just be honest and say "You may have a branch whose name begins with a '%'
and you cannot refer to it anymore in certain contexts. Too bad. Don't
do it next time you create a new branch". I _can_ buy that argument.
It however asks for a sane escape hatch. You cannot "fix" such branch
names in most obvious ways (if you could, that would be a bug in this %
feature).
(1) git branch -m %master percent-master
We would end up renaming what master tracks to new name.
(2) git branch percent-master refs/heads/%master; git branch -d %master
The first part is a good try, but the latter deletes what master
tracks.
"git update-ref -d refs/heads/%master" needs to replace the second step of
the latter.
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Björn Steinbrink @ 2009-03-20 17:08 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher,
git
In-Reply-To: <alpine.DEB.1.00.0903201714020.10279@pacific.mpi-cbg.de>
On 2009.03.20 17:17:01 +0100, Johannes Schindelin wrote:
> Even if a branch name can legally start with a '%' sign, we can use the
> special character '%' here, as you can always specify the full ref:
> refs/heads/%my-branch (pointed out by doener on IRC).
Hm, I just recalled that "git checkout" doesn't "like" anything but the
shortname for a branch, with refs/heads/master or heads/master, you get
a detached HEAD. Though at least when reading the doc, that seems like a
bug to me. The man page says:
When this parameter names a non-branch (but still a valid commit
object), your HEAD becomes detached.
And of course refs/heads/master names a branch. Is it
expected/intended that checkout detaches HEAD anyway when given a full
ref name?
Björn
^ permalink raw reply
* Re: [PATCH v2 1/2] Introduce config variable "diff.defaultOptions"
From: Keith Cascio @ 2009-03-20 17:11 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090320070148.GD27008@coredump.intra.peff.net>
Peff,
Thank you for this extremely thoughtful reply. First, I want to ease concern
over the point about "intent-to-change". BTW, everything I describe here is
already implemented in v3.
On Fri, 20 Mar 2009, Jeff King wrote:
> Look, I am not opposed to layer flattening if that's what is required to get
> it right. But consider the downside of layer flattening: we must always record
> intent-to-change when making a change to the struct (i.e., the "mask" variable
> in your original patches). This is fine for members hidden behind macros, but
> there are a lot of members that are assigned to directly. We would need to:
>
> 1. Introduce new infrastructure for assigning to these members.
Only the bit flag fields need special infrastructure! IOW, the macros are only
necessary for the bit flags. For numeric data or pointer data, there's no need
to keep extra state, and there's no need for callsites to change from direct
assignment. Only for bit flags, we need an extra bit to remember whether the
value is pristine or not. For all other data:
(a) numeric data (integers, chars, and floats): define magic value(s) that
represent pristineness. Initialize all fields to PRISTINE. Later, if a field
has any value other than PRISTINE, we know there was intent-to-change.
(b) pointer data: NULL is the pristine value. Any value other than NULL means
intent-to-change.
> 2. Fix existing locations by converting them to this infrastructure.
As of 628d5c2, all callsites that set bit flags are already updated to use the
macros. As mentioned above, all other locations can keep on keepin' on using
direct assignment. No change here.
> 3. Introduce some mechanism to help future callers get it right (since
> otherwise assigning directly is a subtle bug).
Yes, in the future, someone could write naughty code that sets a bit flag
directly rather than using one of the macros. In C, we probably can't make that
impossible. But generally speaking we can't protect against all forms of gross
negligence. In order to commit his crime, this hypothetical programmer must
ignore the fact that these bits are never set directly, anywhere in the code,
period. A competent programmer would, after deciding that he needs to set a
bit, look at other spots where such bits are set, and mimic. I think the normal
patch auditing process this community follows would raise alarms on patches
coming from negligent programmers (there are always tell-tale signs). And, in
the event that, nevertheless, Junio applies a bit-flag-direct-assignment patch,
it will result in a bug of precisely the following form: an explicitly-given
command-line option to a porcelain command fails to override a default option.
It will be noticed and fixed. It's not fatal, it doesn't corrupt data, it
affects only porcelain and it's not hidden. Of all the insect kingdom (grand
scheme of hypothetical bugs), this one isn't worth abandoning a good design
over.
All in all, turns out v3 requires surprisingly little modification of existing
code outside of diff.h/diff.c. Actually, it only adds 3 lines, that's it!!
builtin-diff.c | 2 +
builtin-log.c | 1 +
diff.c | 112 ++++++++++++++++++++++++-
diff.h | 17 +++-
Shall I post v3?
-- Keith
^ permalink raw reply
* Re: Status of GIT for Fedora 10 + gitweb's look
From: J.H. @ 2009-03-20 16:21 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <B041B86F1FF246ACBD68051753788FBE@HPLAPTOP>
If your on Fedora 10 to get gitweb installed all you should have to do is:
yum install gitweb
and you will be off and running.
- John 'Warthog9' Hawley
Aaron Gray wrote:
> I tried installing Git on F10 and got the following :-
>
> [root@localhost ~]# rpm -Uvh git-1.6.2.1-1.fc9.i386.rpm
> error: Failed dependencies:
> perl-Git = 1.6.2.1-1.fc9 is needed by git-1.6.2.1-1.fc9.i386
> git = 1.6.0.6-3.fc10 is needed by (installed)
> perl-Git-1.6.0.6-3.fc10.i386
> git = 1.6.0.6-3.fc10 is needed by (installed)
> git-svn-1.6.0.6-3.fc10.i386
> git = 1.6.0.6-3.fc10 is needed by (installed)
> git-daemon-1.6.0.6-3.fc10.i386
> git = 1.6.0.6-3.fc10 is needed by (installed)
> gitweb-1.6.0.6-3.fc10.i386
>
>
> Can I install from source I could only find F9 SRPMS.
>
> What I am really after knowing is gitweb on the latest version 1.6.2.1
> anything like the nice HTML layout on http://git.kernel.org/ or do I
> have to do the html formatting myself in the perl code ?
>
> Many thanks in advance,
>
> Aaron
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Status of GIT for Fedora 10 + gitweb's look
From: Todd Zullinger @ 2009-03-20 17:31 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <B041B86F1FF246ACBD68051753788FBE@HPLAPTOP>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
Aaron Gray wrote:
> What I am really after knowing is gitweb on the latest version
> 1.6.2.1 anything like the nice HTML layout on http://git.kernel.org/
> or do I have to do the html formatting myself in the perl code ?
The gitweb included in the 1.6.0.6 packages for F-10 should look
mostly the same as the gitweb used on kernel.org. As JH mentioned,
you can install that with 'yum install gitweb'. If you need to modify
them, the options and css should let you do what you need without
editing the perl script.
If you do want to use 1.6.2.1, the rawhide packages should rebuild for
F-10 just fine (do note that the rawhide packages finally caught up
and moved the git-* binaries out of $PATH, something that isn't done
in the stock F-10 packages).
The fedora rawhide git packages are at:
http://mirrors.kernel.org/fedora/development/source/SRPMS/git-1.6.2-1.fc11.src.rpm
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When life gives you lemons, make lemonade, pee in it, and serve it to
the people that piss you off.
-- Jack Handy, Deep Thoughts
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
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