Style clean up, as requested, followed by the fix to the "both sides added"
handling for git-merge-one-file.
This is based on v4 of my p4merge series, as they touch the same area.
Kevin Bracey (3):
git-merge-one-file: style cleanup
git-merge-one-file: send "ERROR:" mess
new base) appear in blue; changes that do not
appear in the rebased commit (from the new base, or common to both) are
in green. If Perforce had rebase, they'd probably not swap ours/theirs,
but make P4Merge show common changes in blue, picking out our changes in
green. We can't do that, s
Update style to match Documentation/CodingGuidelines.
Signed-off-by: Kevin Bracey
---
git-merge-one-file.sh | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 255c07a..2382b1f 100755
--- a/git-merge
Signed-off-by: Kevin Bracey
---
git-merge-one-file.sh | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 2382b1f..39b7799 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -69,7 +69,7 @@ case &quo
ch without
this flaw.
Signed-off-by: Kevin Bracey
---
git-merge-one-file.sh | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 39b7799..e231d20 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-fil
same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.
Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files. As with the other merge
After printing the list of left-behind commits (with abbreviated
hashes), use an abbreviated hash in the suggested 'git branch' command;
there's no point in outputting a full 40-character hex string in some
friendly advice.
Signed-off-by: Kevin Bracey
---
builtin/checkout.c
/ / /
I B D
\ / /
`-'
After 4b7f53 you instead get:
.-A---M N---O
/ / / /
I B / D
\ / / /
`-'
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the b
parent.
So, how to automatically find a merge that ignored a known change?
And then for visualisation purposes, how do you persuade gitk's diff
display to actually show that that merge commit removed the change from
one of its parents? Again, "-m" didn't seem to work.
Help
On 09/04/2013 21:00, Kevin Bracey wrote:
So, how to automatically find a merge that ignored a known change?
I think I've found the problem. It only doesn't work _if you specify the
file_.
Specifically, if I was missing an addition, my first attempt to find it
would be
git lo
The usage string for cherry-pick and revert has never been updated to
reflect their ability to handle multiple commits. Other documentation is
already correct.
Signed-off-by: Kevin Bracey
---
builtin/revert.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin
only if it is TREESAME to
_all_ parents. This means the command above locates a merge that dropped
"change".
Signed-off-by: Kevin Bracey
---
This would address my problem case - it passes existing tests, and covers
my (all-too-common) problem. But it would also need documentation change
On 22/04/2013 22:49, Junio C Hamano wrote:
>
> So in addition to "have some change and there is no same parent"
> case, under _some_ condition we avoid marking a merge not worth
> showing (i.e. TREESAME) if there is any change.
>
> And the condition is !simplify_history and !simplify_merges, which
erge.
And maybe there's more simplify_merges could do, if it had this full
TREESAME information available.
(But even after you do all this stuff to get the right commits out, we
then hit a niggle of mine that gitk forces --cc diffs - even if it shows
shows the offending merge commit,
On 25/04/2013 19:51, Junio C Hamano wrote:
Kevin Bracey writes:
Thanks for the test addition. Maybe we will be able to satisfy your
greed in this series. There could be more worth doing here, and I
think getting TREESAME precise is key.
It is perfectly fine to do things one step at a time
and it
also gets the examples in the manual right. (I've extended the examples
to include the irrelevant side branch - not sure this is worthwhile, as
it's such an unusual case, and I think that section is confusing enough
for newbies...)
Kevin
--
To unsubscribe from this list
oving
a parent. This is achieved by storing per-parent TREESAME flags on the
initial scan, so the combined flag can be easily recomputed.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 2 +-
revision.c | 220 +
In the event of an odd merge, we may find ourselves TREESAME to
apparently redundant parents. Prevent simplify_merges() from removing
every TREESAME parent - in the event of such a merge it's useful to see
where we came actually from came.
Signed-off-by: Kevin Bracey
---
Documentation/rev
hat touches
the paths we are following) are independent from each other, and
both need to be kept.
That is incorrect; when the side branch 'x' never touches the paths,
it should be removed to allow M to simplify down to the last commit
on the main history that touches the
On 28/04/2013 02:02, Junio C Hamano wrote:
Kevin Bracey writes:
In the event of an odd merge, we may find ourselves TREESAME to
apparently redundant parents. Prevent simplify_merges() from removing
every TREESAME parent - in the event of such a merge it's useful to see
where we came act
On 28/04/2013 01:36, Junio C Hamano wrote:
Kevin Bracey writes:
Historically TREESAME was set on a commit if it was TREESAME to _any_ of
its parents. This is not optimal, as such a merge could still be worth
showing, particularly if it is an odd "-s ours" merge that (possibly
ac
the
same reason M does not appear in your earlier IABNDOP output, no?
That's the topology I was thinking of. Yes, P is then "full-TREESAME"
like M, but it's just a more typical example of a real merge and why
TREESAMEness arises than M is. M didn't appear in full-histor
From: Junio C Hamano
Signed-off-by: Junio C Hamano
---
t/t6012-rev-list-simplify.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh
index dd6dc84..4e55872 100755
--- a/t/t6012-rev-list
e followed.
This avoids producing a totally disjoint history from the default log
when the default log is a better explanation of the end result, and aids
visualisation of odd merges.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 3 +-
revision.c
reak the linear hash collision
search. But we can remove NULL decoration entries when rebuilding the
table.
Signed-off-by: Kevin Bracey
---
decorate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/decorate.c b/decorate.c
index 2f8a63e..7cb5d29 100644
--- a/decorate.c
+
In the example given, P is not TREESAME to E. This doesn't affect the
current result, but it will matter when we change behaviour.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/rev
scripting, and on
top of that something like this could really do with an independent
set of eyes checking that the claimed benefits actually match the
results. (And that the claims are understandable.)
Junio C Hamano (1):
t6012: update test for tweaked full-history traversal
Kevin Bracey (7):
hat touches
the paths we are following) are independent from each other, and
both need to be kept.
That is incorrect; when the side branch 'x' never touches the paths,
it should be removed to allow M to simplify down to the last commit
on the main history that touches the
very
change to the file, including those changes' ultimate fate in merges.
Also modify simplify_merges to recalculate TREESAME after removing
a parent. This is achieved by storing per-parent TREESAME flags on the
initial scan, so the combined flag can be easily recomputed.
Signed-off-
igher up the graph, I is INTERESTING and thus privileged over F, so we
don't care that J differs from F.
So should we treat bottom commits as "interesting" for the rules above?
Signed-off-by: Kevin Bracey
---
revision.c| 141 --
ions.
Signed-off-by: Kevin Bracey
---
t/t6019-rev-list-ancestry-path.sh | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/t/t6019-rev-list-ancestry-path.sh
b/t/t6019-rev-list-ancestry-path.sh
index 39b4cb0..86ef908 100755
--- a/t/t6019-rev-list-ancestry-p
on in limited revision
lists - irrelevant merges from unlisted commits can be omitted.
Signed-off-by: Kevin Bracey
---
revision.c| 210 --
revision.h| 3 +-
t/t6019-rev-list-ancestry-path.sh | 12 ++-
3 files
on in limited revision
lists - irrelevant merges from unlisted commits can be omitted.
Signed-off-by: Kevin Bracey
---
Something went wrong with v2.1; it got based on an old version of the series.
This one should apply to v2 correctly.
revision.c
important to them. So let's
be helpful and meet normal expectation, and treat the edge between the
INTERESTING graph and the specified bottom commit as important.
Revised patch 8/8 doing this follows. The fact it adds a BOTTOM flag
potentially has an impact on other areas, as noted in
Thanks! I'll include that fix.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-or-so-item test set, with about 15
"failures" in a variety of modes that get fixed by this sequence. I
think that should make an excellent discussion topic. We'll see whether
folks agree with my view about what should and shouldn't be shown...
Kevin
--
To unsubscribe from th
Some side branching and odd merging to illustrate various flaws in
revision list scans, particularly when limiting the list.
Many expected failures, which will be gone by the end of the "history
traversal refinements" series.
Signed-off-by: Kevin Bracey
---
t/t6111-rev-list-treesam
From: Junio C Hamano
Signed-off-by: Junio C Hamano
---
t/t6012-rev-list-simplify.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh
index dd6dc84..4e55872 100755
--- a/t/t6012-rev-list
e followed.
This avoids producing a totally disjoint history from the default log
when the default log is a better explanation of the end result, and aids
visualisation of odd merges.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 3 +-
revision.c
In the example given, P is not TREESAME to E. This doesn't affect the
current result, but it will matter when we change behaviour.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/rev
quot;?
Junio C Hamano (1):
t6012: update test for tweaked full-history traversal
Kevin Bracey (8):
decorate.c: compact table when growing
t6019: test file dropped in -s ours merge
t6111: new TREESAME test set
rev-list-options.txt: correct TREESAME for P
revision.c: Make --full-history
ESAME to 1 parent, so are treated as TREESAME and not shown. This is
clearly undesirable in the case of merge L, which dropped our G.t by
taking the non-ancestry-path version. Document this as a known failure,
and expect "H J L", the 3 merges along the path that had to chose G.t
versions.
reak the linear hash collision
search. But we can remove NULL decoration entries when rebuilding the
table.
Signed-off-by: Kevin Bracey
---
decorate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/decorate.c b/decorate.c
index 2f8a63e..7cb5d29 100644
--- a/decorate.c
+
hat touches
the paths we are following) are independent from each other, and
both need to be kept.
That is incorrect; when the side branch 'x' never touches the paths,
it should be removed to allow M to simplify down to the last commit
on the main history that touches the
on in limited revision
lists - irrelevant merges from unlisted commits can be omitted.
Signed-off-by: Kevin Bracey
---
revision.c| 201 --
revision.h| 3 +-
t/t6019-rev-list-ancestry-path.sh | 12 ++-
t/t
11 failures, but creates a couple of new ones -
we are now showing some merges that don't need to be shown.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 6 +-
revision.c | 241 -
revision.h
ults for
"A...B" compared to "A B ^AB_base".
So ensure that the calculated merge bases are sent to add_rev_cmdline(),
flagged as 'REV_CMD_MERGE_BASE'.
Signed-off-by: Kevin Bracey
---
revision.c | 9 +++--
revision.h | 2 ++
On 06/05/2013 23:45, Junio C Hamano wrote:
Kevin Bracey writes:
+struct treesame_state {
+ unsigned int nparents;
+ unsigned char treesame[FLEX_ARRAY];
+};
I have been wondering if we want to do one-bit (not one-byte) per
parent but no biggie ;-)
I did start down that path
On 06/05/2013 23:36, Junio C Hamano wrote:
Kevin Bracey writes:
+#,---E--. *H--. * marks !TREESAME parent paths
+# /\ / \*
+# *A--*B---D--*F-*G-K-*L-*M
+# \ /* \ /
+#`-C-' `-*I-*J
+#
+# A cr
On 07/05/2013 00:24, Junio C Hamano wrote:
Kevin Bracey writes:
The documentation assures users that "A...B" is defined as 'r1 r2 --not
$(git merge-base --all r1 r2)'. This isn't in fact quite true, because
the calculated merge bases are not sent to add_rev_cmdline().
On Sep 19, 2012, at 1:37 PM, Jeff King wrote:
> On Wed, Sep 19, 2012 at 01:31:50PM -0700, Kevin Ballard wrote:
>
>>> I am a little lukewarm on my patch if only because of the precedent it
>>> sets. There are a trillion options that revision.c parses that are not
>&
gument, just print out a helpful message saying blame
already follows renames (and then continue with the blame anyway, so
as to not set a precedent to abort on unknown-but-currently-accepted
flags).
-Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Konstantin,
thanks for the reply.
The versions of git are:
- on remote: 1.5.6.5
- on windows build machine: 1.7.11.msysgit.1
- on mac build machine: 1.7.3.4
I will try to install latest git version on my remote server and get
back to you.
thanks again
Kevin
On 10/29/12 6:18 PM
I tried to install git 1.8 on the remote server and get exactly the same
problem :(.
Kevin
On 10/29/12 6:18 PM, Konstantin Khomoutov wrote:
On Mon, 29 Oct 2012 09:52:54 -0700 (PDT)
Kevin Molcard wrote:
I have a problem with my build system.
I have a remote server with a relatively large
Hi all,
I am forwarding a reply I got from a message I sent to git user mailing
list because of a "bad pack header error" (more information below).
I will forward another email where I give all the git versions of my system.
Any clue on this would be much appreciated.
Thanks in adv
command on
from the mac and 2 from the Windows and it seems to always fails on the
Windows).
Thanks again
Kevin
Original Message
Subject: Re: [git-users] Git clone fails with "bad pack header", how to
get remote log
Date: Wed, 31 Oct 2012 15:28:37 +0400
From:
Yes I can,
can you tell me how I have to do that?
thanks
Kevin
On 10/31/12 3:19 PM, Jeff King wrote:
On Tue, Oct 30, 2012 at 03:57:36PM +0100, kevin molcard wrote:
I tried to install git 1.8 on the remote server and get exactly the
same problem :(.
[...]
Sometimes (very often when several
I forgot to mention that I am using scm manager:
https://bitbucket.org/sdorra/scm-manager/wiki/Home
So that maybe the " custom layer you are talking about.
Kevin
On 10/31/12 3:19 PM, Jeff King wrote:
On Tue, Oct 30, 2012 at 03:57:36PM +0100, kevin molcard wrote:
I tried to install gi
Hi Peff,
thanks for this information.
I will report the issue to scm-manager. In the meantime I will try to
use ssh protocol to connect to my remote server.
Thanks again,
Kevin
2012/11/1 Jeff King :
> On Wed, Oct 31, 2012 at 03:34:22PM +0100, kevin molcard wrote:
>
>> I forgot to me
racking capabilities, not dependent on network access to a central
server." I'm sure there are better wordings, but I hate to point out an
problem without offering at least one possible improvement.
Kevin
[1] I believe that ArX, monotone, codeville, and svk all fall into this
categ
her
assumptions. There are tricks the user can use to force the save icon
on, but it's not intuitive.
So we now follow a suggestion given in the original patch's discussion:
generate a virtual base, consisting of the lines common to the two
branches. It produces a much nicer 3-way diff v
uot;) for a diff,
while it's another branch (ie "theirs") for a merge.
Signed-off-by: Kevin Bracey
---
mergetools/p4merge | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 8a36916..46b3a5a 100644
--- a/mergetools/p4m
so I may have
made some blunder there.
Kevin Bracey (2):
p4merge: swap LOCAL and REMOTE for mergetool
p4merge: create a virtual base if none available
git-mergetool--lib.sh | 14 ++
mergetools/p4merge| 4 ++--
2 files changed, 16 insertions(+), 2 deletions(-)
--
1.8.2.
On 07/03/2013 02:36, Junio C Hamano wrote:
Kevin Bracey writes:
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
Given that the ordering of
On 07/03/2013 04:23, David Aguilar wrote:
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey wrote:
+make_virtual_base() {
+ # Copied from git-merge-one-file.sh.
I think the reasoning behind these patches is good.
How do we feel about this duplication?
Bad.
Should we make a common
My only reservation is that I assume it would be implemented by swapping
what's passed in $LOCAL and $REMOTE. Which seems a bit icky:
$LOCAL="a.REMOTE.1234.c". On the other hand, $LOCAL and $REMOTE are
already not very meaningful names for difftool... Maybe we should change
to us
new base) appear in blue; changes that do not
appear in the rebased commit (from the new base, or common to both) are
in green. If Perforce had rebase, they'd probably not swap ours/theirs,
but make P4Merge show common changes in blue, picking out our changes in
green. We can't do that, so
ch without
this flaw.
Signed-off-by: Kevin Bracey
---
git-merge-one-file.sh | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 1236fbf..70f36f1 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-fil
ption, and I failed to come up with anything remotely elegant.
Kevin Bracey (3):
mergetools/p4merge: swap LOCAL and REMOTE
mergetools/p4merge: create a base if none available
git-merge-one-file: revise merge error reporting
git-merge-one-file.sh | 38
same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.
Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files. As with the other merge
"git help" translated the "See 'git help ' for more
information..." message, but "git" didn't.
Signed-off-by: Kevin Bracey
---
git.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git.c b/git.c
index d33f9b3..e484644 100644
--
o the only change to existing command behaviour is that "git help" or
"git help -w" now opens the git manual page, rather than showing common
commands.
"git -h cmd" is also accepted as a synonym for "git cmd -h", as per
Linus's rationale for treatin
Re-ordered option list in command-line usage to match the manual page.
Also makes it less than 80-characters wide.
Signed-off-by: Kevin Bracey
---
git.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index d33f9b3..2a98624 100644
--- a/git.c
+++ b/git.c
On 11/03/2013 21:58, Junio C Hamano wrote:
Kevin Bracey writes:
Re-ordered option list in command-line usage to match the manual page.
Also makes it less than 80-characters wide.
Thanks (s/Re-ordered/reorder/ and s/makes/make/, though).
Got it. But I'm going to reword it, to follo
Make the command line use the narrower synopsis layout that the man page
has used since commit 68e4b55.
Signed-off-by: Kevin Bracey
---
git.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index d33f9b3..2a98624 100644
--- a/git.c
+++ b/git.c
@@ -6,10
curred to me it would be there under "-h" instead.
So how about going further than that patch, and making it even simpler.
Collapse --help and -h to be synonyms. Then under either spelling,
--help|-h always shows usage for "git" or "git ", as per GNU
guidelines.
Then the manual launch only happens for "git help ..." and, "git help"
on its own launches the root. And the output of "git [--help]" ends with:
See 'git help []' for more information.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.
Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files. As with the other merge
ch without
this flaw.
Signed-off-by: Kevin Bracey
---
git-merge-one-file.sh | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 0f164e5..78b07a8 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-fil
new base) appear in blue; changes that do not
appear in the rebased commit (from the new base, or common to both) are
in green. If Perforce had rebase, they'd probably not swap ours/theirs,
but make P4Merge show common changes in blue, picking out our changes in
green. We can't do that, so
On 13/03/2013 19:57, Junio C Hamano wrote:
Kevin Bracey writes:
- echo "Added $4 in both, but differently."
+ echo "ERROR: Added $4 in both, but differently."
+ ret=1
The problem you identified may be worth fixing, but I do not
On 14/03/2013 16:56, Junio C Hamano wrote:
Kevin Bracey writes:
Maybe the virtual base itself should be different. Maybe it should put
a ??? marker in place of every unique line. So you get:
Left ABCEFGH
Right XABCDEFJH -> Merge result <|X>ABC<|D>EFH
VBase ?ABC?EF??H
On 14/03/2013 19:31, Kevin Bracey wrote:
On 14/03/2013 16:56, Junio C Hamano wrote:
Well, yes, but I would assume that we would forcibly select normal
diff here somehow, if we aren't already. We should be - turning
ABCDEFGH vs ABCD into ABCD is silly.
Doh. But anyway, we don'
t when there are opportunities to make
the data structures more generally useful without causing problems for
the kernel project, I hope they are taken.
Thanks,
Kevin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More
for kernel development. I'm just trying to clarify the
facts so everyone can understand what darcs is trying to do.
Kevin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ray Lee wrote:
> On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote:
>
>>>>The other is "replace very instace of identifier `foo` with
>>>>identifier`bar`".
>>>
>>>That could be derived, however, by a particularly smart parser [1].
>
t renames are merely a special case of code moves.
His implementation ideas are quite different from git, but I thought it
was pretty cool to find that someone was thinking about these ideas a
couple years ago.
Kevin
-
To unsubscribe from this list: send the line "unsubscribe git" in
t
> a) what the software should do and
> b) how You should tell it?
I agree that it would be nice to have automated unit tests.
> And of course there are still memory leaks.
The code is still young, and these will be fixed. I'm not bothered that
there are leaks at this moment. I am
Ingo Molnar wrote:
> * Kevin Smith <[EMAIL PROTECTED]> wrote:
>
>>Git is very immature, and currently should only be used by brave
>>pioneers. About the only way for a mortal to even try git is to stick
>>to git-pasky releases, and not try to track all the patc
Ray Lee wrote:
> On Mon, 2005-04-18 at 22:05 -0400, Kevin Smith wrote:
>
>>Notice that just by looking at my diffs, you can't tell that I used a
>>replace operation.
>
>
> Here's where we disagree. If you checkpoint your tree before the
> replace, and im
e has strongly indicated that folks who want to build on top
of it should not expect to see libgit any time soon, so git will be an
important independent tool.
But presumably you'll change the name of this package to cogito soon
anyway, as soon as git-pasky itself is renamed.
Kevin
-
a money to spend on hosting accounts.
This happens to be a hot button issue for me, in case you can't tell.
Sorry if I'm ranting.
Kevin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
's inside git (the source code) is not actually
code that can be built but metadata describing the configuration of a product
that's used to deploy the parameters.
Thanks for reading this request.
Kevin GOSSENT
This message contains information that may be privileged or confidential and
objects: 100% (1879/1879), done.
It would be useful to be able to turn off individual warnings during
cloning. Is there something I’m missing in the config? Or, is this
something that could be fixed?
Thanks,
Kevin
--
Kevin A. Mitchell
http://www.kamit.com/
w to Git so I don't know when/why that was
changed but somewhere along the way, that change broke git subtree add. :( A
workaround is to use lightweight tags but that's not suitable for some.
Thanks,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
401 - 494 of 494 matches
Mail list logo
