* Re: git rebase --continue with goofy error
From: Michael J Gruber @ 2008-12-04 16:32 UTC (permalink / raw)
To: Adrian Klingel; +Cc: git
In-Reply-To: <5AC243B6-F048-4286-80E1-1D0E695792B9@illumaware.com>
Adrian Klingel venit, vidit, dixit 04.12.2008 15:55:
> I am trying so, so hard to rebase a branch with updates made in master:
>
> *********
> git rebase master
> *********
>
> I get about 20 conflicts back, which I fix and do:
>
> *********
> git add *
> *********
>
> There were also many, many error messages after the rebase command, eg:
>
> *********
> error: test/unit/missing_year_test.rb: already exists in index
> error: test/unit/axle_test.rb: already exists in index
> error: test/unit/body_style_test.rb: already exists in index
> error: test/unit/brake_test.rb: already exists in index
> error: test/unit/category_test.rb: already exists in index
> error: test/unit/comment_test.rb: already exists in index
> error: test/unit/company_comment_test.rb: does not exist in index
> error: test/unit/country_test.rb: already exists in index
> *********
>
>
> but I ignore that error, because I have no idea what it means. If I
Not a good general approach. If there are errors to begin with there is
no reason to expect success later on.
Here, I assume you are starting from a dirty working tree. What did git
status say before the rebase?
> were to guess, I'd say it's trying to copy files from master to my
> current branch. Of course.
>
> So now I have added my conflict fixes, per the message:
>
> *********
> Failed to merge in the changes.
> Patch failed at 0002.
>
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --
> abort".
> *********
What command triggered that message? It's certainly not saying that you
have added your conflict fixes, as you seem to think.
>
> So I decide to continue:
>
> *********
> git rebase --continue
> *********
>
>
> And I get the following:
>
> *********
> mymac:/Library/mydir/code/myapp me$ git rebase --continue
> Unknown option: 1
> Usage: head [-options] <url>...
> -m <method> use method for the request (default is 'HEAD')
> -f make request even if head believes method is illegal
> -b <base> Use the specified URL as base
> -t <timeout> Set timeout value
> -i <time> Set the If-Modified-Since header on the request
> -c <conttype> use this content-type for POST, PUT, CHECKIN
> -a Use text mode for content I/O
> -p <proxyurl> use this as a proxy
> -P don't load proxy settings from environment
> -H <header> send this HTTP header (you can specify several)
>
> -u Display method and URL before any response
> -U Display request headers (implies -u)
> -s Display response status code
> -S Display response status chain
> -e Display response headers
> -d Do not display content
> -o <format> Process HTML content in various ways
>
> -v Show program version
> -h Print this message
>
> -x Extra debugging output
> Applying
> You still have unmerged paths in your index
> did you forget to use 'git add'?
>
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --
> abort".
>
> *********
>
>
> A google search of "git" and "Unknown option: 1" yields zero
> results.
As the "Usage: head..." tells us, the message comes from the command
"head", not from git. (head is used by git-rebase -i)
> Notice I did not commit the adds. I didn't think it made
> sense to do that, since I imagine that is what the rebase is doing
> anyway?
>
> This is on git version 1.5.5.3.
>
> Should I upgrade git? Will that break any repos that I have?
Yes! No!
Cheers,
Michael
^ permalink raw reply
* Re: git rebase --continue with goofy error
From: Björn Steinbrink @ 2008-12-04 16:27 UTC (permalink / raw)
To: Adrian Klingel; +Cc: git
In-Reply-To: <5AC243B6-F048-4286-80E1-1D0E695792B9@illumaware.com>
On 2008.12.04 09:55:55 -0500, Adrian Klingel wrote:
> And I get the following:
>
> *********
> mymac:/Library/mydir/code/myapp me$ git rebase --continue
> Unknown option: 1
> Usage: head [-options] <url>...
> -m <method> use method for the request (default is 'HEAD')
> -f make request even if head believes method is illegal
> -b <base> Use the specified URL as base
> -t <timeout> Set timeout value
> -i <time> Set the If-Modified-Since header on the request
> -c <conttype> use this content-type for POST, PUT, CHECKIN
> -a Use text mode for content I/O
> -p <proxyurl> use this as a proxy
> -P don't load proxy settings from environment
> -H <header> send this HTTP header (you can specify several)
>
> -u Display method and URL before any response
> -U Display request headers (implies -u)
> -s Display response status code
> -S Display response status chain
> -e Display response headers
> -d Do not display content
> -o <format> Process HTML content in various ways
>
> -v Show program version
> -h Print this message
>
> -x Extra debugging output
That comes via git-am which used to call "head -1", but using -<n> is
deprecated and apparently not supported anymore by modern versions of
coreutils. Was fixed in:
1d9b2656: git-am: head -1 is obsolete and doesn't work on some new systems
Which is in git 1.5.6.
Björn
^ permalink raw reply
* Re: git rebase --continue with goofy error
From: Adrian Klingel @ 2008-12-04 16:24 UTC (permalink / raw)
To: git
In-Reply-To: <9F631552-BA29-4A85-9A85-2992232CDDE6@railsnewbie.com>
That's the problem. I've resolved the conflicts, added everything.
Then I run git rebase --continue and that's what I get. After I do
the adds, am I supposed to commit them?
Adrian Klingel
President/CEO
Illumaware, LLC
Adrian.Klingel@illumaware.com
phone: 800.880.4964
outside US: 919.783.4037
fax: 919-882.9447
On Dec 4, 2008, at 10:52 AM, Scott Taylor wrote:
>
> On Dec 4, 2008, at 9:55 AM, Adrian Klingel wrote:
>
>> I am trying so, so hard to rebase a branch with updates made in
>> master:
>>
>> *********
>> git rebase master
>> *********
>>
>> I get about 20 conflicts back, which I fix and do:
>>
>> *********
>> git add *
>> *********
>>
>> There were also many, many error messages after the rebase
>> command, eg:
>>
>> *********
>> error: test/unit/missing_year_test.rb: already exists in index
>> error: test/unit/axle_test.rb: already exists in index
>> error: test/unit/body_style_test.rb: already exists in index
>> error: test/unit/brake_test.rb: already exists in index
>> error: test/unit/category_test.rb: already exists in index
>> error: test/unit/comment_test.rb: already exists in index
>> error: test/unit/company_comment_test.rb: does not exist in index
>> error: test/unit/country_test.rb: already exists in index
>> *********
>>
>>
>> but I ignore that error, because I have no idea what it means. If
>> I were to guess, I'd say it's trying to copy files from master to
>> my current branch. Of course.
>>
>> So now I have added my conflict fixes, per the message:
>>
>> *********
>> Failed to merge in the changes.
>> Patch failed at 0002.
>>
>> When you have resolved this problem run "git rebase --continue".
>> If you would prefer to skip this patch, instead run "git rebase --
>> skip".
>> To restore the original branch and stop rebasing run "git rebase --
>> abort".
>> *********
>>
>>
>> So I decide to continue:
>>
>> *********
>> git rebase --continue
>> *********
>>
>>
>> And I get the following:
>>
>> *********
>> mymac:/Library/mydir/code/myapp me$ git rebase --continue
>> Unknown option: 1
>> Usage: head [-options] <url>...
>> -m <method> use method for the request (default is 'HEAD')
>> -f make request even if head believes method is illegal
>> -b <base> Use the specified URL as base
>> -t <timeout> Set timeout value
>> -i <time> Set the If-Modified-Since header on the request
>> -c <conttype> use this content-type for POST, PUT, CHECKIN
>> -a Use text mode for content I/O
>> -p <proxyurl> use this as a proxy
>> -P don't load proxy settings from environment
>> -H <header> send this HTTP header (you can specify several)
>>
>> -u Display method and URL before any response
>> -U Display request headers (implies -u)
>> -s Display response status code
>> -S Display response status chain
>> -e Display response headers
>> -d Do not display content
>> -o <format> Process HTML content in various ways
>>
>> -v Show program version
>> -h Print this message
>>
>> -x Extra debugging output
>> Applying
>> You still have unmerged paths in your index
>> did you forget to use 'git add'?
>>
>> When you have resolved this problem run "git rebase --continue".
>> If you would prefer to skip this patch, instead run "git rebase --
>> skip".
>> To restore the original branch and stop rebasing run "git rebase --
>> abort".
>>
>> *********
>>
>>
>> A google search of "git" and "Unknown option: 1" yields zero
>> results. Notice I did not commit the adds. I didn't think it
>> made sense to do that, since I imagine that is what the rebase is
>> doing anyway?
>>
>
> I'm not sure what the first part of this is saying (The "unknown
> option").
>
> The important part is later on:
>
> You still have unmerged paths in your index
> did you forget to use 'git add'?
>
> After you resolve any conflicts, make sure to git add any remaining
> files before you "rebase --continue"
>
> Regards,
>
> Scott
>
>
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Jeremy Ramer @ 2008-12-04 16:05 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0812041141160.9969@ds9.cixit.se>
On Thu, Dec 4, 2008 at 3:43 AM, Peter Krefting <peter@softwolves.pp.se> wrote:
> Hi!
>
> When using Git on Windows, it doesn't pick up a user name from the
> environment, which leads to commits made by git gui (and probably by
> git itself) to show up as being made by "unknown <username@.(none)>"
> (where "username" is the Windows account name).
That's strange. I am using git 1.6.0.4 on cygwin and I get a warning
message every time I start git gui. I actually find this really
annoying and would like a way to turn this warning message off.
>
> Is it possible to add a warning to git-gui the first time a commit is
> attempted if the e-mail address is not configured, and have the user
> open the configuration dialogue to set up the name properly?
>
> --
> \\// Peter - http://www.softwolves.pp.se/
> --
> 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: [PATCH] gitk: fix 'can't read "notflag"'
From: Johannes Sixt @ 2008-12-04 15:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paul Mackerras, Alejandro Riveira, git
In-Reply-To: <alpine.DEB.1.00.0812041609150.7045@racer>
Johannes Schindelin schrieb:
> On Thu, 4 Dec 2008, Johannes Schindelin wrote:
>
>> diff --git a/gitk-git/gitk b/gitk-git/gitk
>
> D'oh. Please apply with -p2.
No; pull -s subtree before you write this patch ;) It's already fixed in
upstream gitk.
-- Hannes
^ permalink raw reply
* git rebase --continue with goofy error
From: Adrian Klingel @ 2008-12-04 14:55 UTC (permalink / raw)
To: git
I am trying so, so hard to rebase a branch with updates made in master:
*********
git rebase master
*********
I get about 20 conflicts back, which I fix and do:
*********
git add *
*********
There were also many, many error messages after the rebase command, eg:
*********
error: test/unit/missing_year_test.rb: already exists in index
error: test/unit/axle_test.rb: already exists in index
error: test/unit/body_style_test.rb: already exists in index
error: test/unit/brake_test.rb: already exists in index
error: test/unit/category_test.rb: already exists in index
error: test/unit/comment_test.rb: already exists in index
error: test/unit/company_comment_test.rb: does not exist in index
error: test/unit/country_test.rb: already exists in index
*********
but I ignore that error, because I have no idea what it means. If I
were to guess, I'd say it's trying to copy files from master to my
current branch. Of course.
So now I have added my conflict fixes, per the message:
*********
Failed to merge in the changes.
Patch failed at 0002.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --
abort".
*********
So I decide to continue:
*********
git rebase --continue
*********
And I get the following:
*********
mymac:/Library/mydir/code/myapp me$ git rebase --continue
Unknown option: 1
Usage: head [-options] <url>...
-m <method> use method for the request (default is 'HEAD')
-f make request even if head believes method is illegal
-b <base> Use the specified URL as base
-t <timeout> Set timeout value
-i <time> Set the If-Modified-Since header on the request
-c <conttype> use this content-type for POST, PUT, CHECKIN
-a Use text mode for content I/O
-p <proxyurl> use this as a proxy
-P don't load proxy settings from environment
-H <header> send this HTTP header (you can specify several)
-u Display method and URL before any response
-U Display request headers (implies -u)
-s Display response status code
-S Display response status chain
-e Display response headers
-d Do not display content
-o <format> Process HTML content in various ways
-v Show program version
-h Print this message
-x Extra debugging output
Applying
You still have unmerged paths in your index
did you forget to use 'git add'?
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --
abort".
*********
A google search of "git" and "Unknown option: 1" yields zero
results. Notice I did not commit the adds. I didn't think it made
sense to do that, since I imagine that is what the rebase is doing
anyway?
This is on git version 1.5.5.3.
Should I upgrade git? Will that break any repos that I have?
Thanks very, very much.
^ permalink raw reply
* Re: [PATCH] gitk: fix 'can't read "notflag"'
From: Johannes Schindelin @ 2008-12-04 15:09 UTC (permalink / raw)
To: Paul Mackerras, Alejandro Riveira; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812041532160.7045@racer>
Hi,
On Thu, 4 Dec 2008, Johannes Schindelin wrote:
> diff --git a/gitk-git/gitk b/gitk-git/gitk
D'oh. Please apply with -p2.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-p4: Fix bug in p4Where method.
From: Tor Arvid Lund @ 2008-12-04 13:37 UTC (permalink / raw)
To: Junio C. Hamano, Simon Hausmann; +Cc: git, Tor Arvid Lund
When running:
p4 where //depot/SomePath/...
The result can in some situations look like:
//depot/SomePath/... //client/SomePath/... /home/user/p4root/SomePath/...
-//depot/SomePath/UndesiredSubdir/... //client/SomePath/UndesiredSubdir/... /home/user/p4root/SomePath/UndesiredSubdir/...
This depends on the users Client view. The current p4Where method will now
return /home/user/p4root/SomePath/UndesiredSubdir/... which is not what we
want. This patch loops through the results from "p4 where", and picks the one
where the depotFile exactly matches the given depotPath (//depot/SomePath/...
in this example).
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com>
---
contrib/fast-import/git-p4 | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 46136d4..7ade777 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -245,7 +245,15 @@ def p4Cmd(cmd):
def p4Where(depotPath):
if not depotPath.endswith("/"):
depotPath += "/"
- output = p4Cmd("where %s..." % depotPath)
+ depotPath = depotPath + "..."
+ outputList = p4CmdList("where %s" % depotPath)
+ output = None
+ for entry in outputList:
+ if entry["depotFile"] == depotPath:
+ output = entry
+ break
+ if output == None:
+ return ""
if output["code"] == "error":
return ""
clientPath = ""
--
1.6.0.2.1172.ga5ed0
^ permalink raw reply related
* [PATCH] gitk: fix 'can't read "notflag"'
From: Johannes Schindelin @ 2008-12-04 14:34 UTC (permalink / raw)
To: Paul Mackerras, Alejandro Riveira; +Cc: git
In-Reply-To: <gh5q1t$qjn$1@ger.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 973 bytes --]
Sometimes, when calling git bisect visualize, parameters including
a "--not" are passed to gitk, triggering an uninitialized-variable bug
introduced in ee66e089(gitk: Make updates go faster).
Noticed by Alejandro Riveira Fernández.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 3 Dec 2008, Alejandro Riveira wrote:
> $ git bisect visualize (03-12 12:16)
> Error in startup script: can't read "notflag": no such variable
Alejandro was good enough to test this fix.
gitk-git/gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3353f4a..b18bdf0 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -139,6 +139,7 @@ proc parseviewargs {n arglist} {
set origargs $arglist
set allknown 1
set filtered 0
+ set notflag 0
set i -1
foreach arg $arglist {
incr i
--
1.6.0.4.1189.g8876f
^ permalink raw reply related
* Re: git alias always chdir to top
From: Jeff King @ 2008-12-04 12:34 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20081203160852.GA3773@osc.edu>
On Wed, Dec 03, 2008 at 11:08:52AM -0500, Pete Wyckoff wrote:
> It looks like handle_alias() uses setup_git_directory_gently() to
> find the .git, which chdir()s up until it gets there. Is there a
> way to do this without changing the process current working
> directory instead? I could even handle an environment variable
> saving the original cwd, but that's ickier.
There has been some discussion of refactoring the setup to _not_ do that
chdir until later, which should fix your problem. And other problems,
too, since aliases can get confused about whether or not we're in a
worktree (try "git config alias.st status && cd .git && git st") as a
result of the startup sequence. Ideally the _only_ thing to happen
before running an alias would be to look at the config to see how to run
the alias, and everything else would be "as if" you had just run the
alias manually.
So no, there's no way to do it correctly right now. The git commands
internally do know the original prefix, but I don't think it is exposed
via the environment.
I hope this will get fixed eventually, but refactoring this code is
unpleasant enough and I have been busy enough that it hasn't happened
yet. You are of course welcome to volunteer. ;)
-Peff
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 2/2]
From: William Pursell @ 2008-12-04 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljuwe2na.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> William Pursell <bill.pursell@gmail.com> writes:
>> Signed-off-by: William Pursell <bill.pursell@gmail.com>
>> ---
>
> It is customary to explain what you changed since v1 here, after the
> three-dash separator, to help reviewers.
Thanks for pointing that out.
>> + elsif ($other =~ 'g' && $line =~ /^g(.*)/) {
>
> I think I fixed this with ($other =~ /g/ && ...) when I queued your
> previous round to 'pu' tonight.
I didn't notice that the first time around. Fixed here.
>
>> + my $response = $1;
>> + my $i = $ix > 10 ? $ix - 10 : 0;
>
> This is different from v1. I understand the motivation (i.e. if you are
> at 73rd hunk of a 100-hunk series, showing hunks 63-83 instead of starting
> from hunk 1-10 would be nicer), but that is something to explain as one of
> the "changes since v1".
>
> I think you are inside a loop that is controlled by another $i (see the
> context in the hunk before this one) and it would be better to use
> different variable, such as $hunk_no (or just $no).
Agreed. Masking enclosing variables is a no-no.
>From 03ae1932337c15cdd20e0d8370782a6343efc5aa Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Thu, 4 Dec 2008 10:22:40 +0000
Subject: [PATCH 2/2] Add 'g' command to go to a hunk.
When a minor change is made while the working directory is in a bit
of a mess, it is somewhat difficult to wade through all of the
hunks using git add --patch. This allows one to jump to the hunk
that needs to be staged without having to respond 'n' to each
preceding hunk.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
changes since v1:
start the summary list from current hunk - 10 rather than 0
replace a statement modifier with a conditional block, for readability
clean up the prompt, so "(<ret> to see more)" appears before '?'
allow trailing whitespace in the user response
changes since v2:
s/goto/go to/
s|=~ 'g'|=~ /g/|
change loop index name from $i to $no, as $i masks a name in the enclosing
scope
git-add--interactive.perl | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index eb11132..ca60356 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -800,6 +800,7 @@ y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
+g - select a hunk to go to
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
@@ -945,6 +946,9 @@ sub patch_update_file {
if ($ix < $num - 1) {
$other .= '/J';
}
+ if ($num > 1) {
+ $other .= '/g';
+ }
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$undecided = 1;
@@ -978,6 +982,28 @@ sub patch_update_file {
}
next;
}
+ elsif ($other =~ /g/ && $line =~ /^g(.*)/) {
+ my $response = $1;
+ my $no = $ix > 10 ? $ix - 10 : 0;
+ while ($response eq '') {
+ my $extra = "";
+ $no = display_hunks(\@hunk, $no);
+ if ($no < $num) {
+ $extra = " (<ret> to see more)";
+ }
+ print "go to which hunk$extra? ";
+ $response = <STDIN>;
+ chomp $response;
+ }
+ if ($response !~ /^\s*\d+\s*$/) {
+ print STDERR "Invalid number: '$response'\n";
+ } elsif (0 < $response && $response <= $num) {
+ $ix = $response - 1;
+ } else {
+ print STDERR "Sorry, only $num hunks available.\n";
+ }
+ next;
+ }
elsif ($line =~ /^d/i) {
while ($ix < $num) {
if (!defined $hunk[$ix]{USE}) {
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* Re: summaries in git add --patch[PATCH 1/2]
From: William Pursell @ 2008-12-04 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdu0e38a.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> William Pursell <bill.pursell@gmail.com> writes:
>
>>> How well does substr() work with utf-8 and other multi-byte encodings
>>> these days, I have to wonder...
>> Hopefully, it works well.
>
> "Hopefully" is the last word I'd like to hear from submitters. It would
> be either "I do not know" or "I studied the topic and I know the code works".
Right. From what I can tell (30 minutes of research, and I
am by no means an expert), perl 5.8 will handle this just
fine with no changes to the code as long as one of the
environment variables LANGUAGE, LC_ALL, LC_TYPE, or LANG
contains either 'UTF-8' or 'UTF8'. With that setting,
all file handles will be opened in UTF8 mode, so the
git diff-files pipe should be parsed appropriately.
I think this is not an issue except with older Perl.
> By the way, I noticed that you are sending your patches with:
>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Please don't. format=flawed tends to destroy whitespaces (I fixed them up
> by hand for the ones I parked in 'pu').
Thanks for pointing that out. Settings changed. I do appreciate
you taking the time to essentially hold my hand through this
process, and hope that I'm not causing you too much extra work.
> I would say "$line =~ /^[-+].*\w/" (i.e. match any +/- line that contains
> a word letter) would be sufficient, and it would be much easier to read.
>
> As you append the entire $line to $summary, there is no need to capture
> with ().
Done.
>
> I think "$i ||= 0" is more customary.
>
Also changed.
>From 2d191d7170948246007cbde5afb28eeb666b3427 Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Thu, 4 Dec 2008 10:00:24 +0000
Subject: [PATCH 1/2] Add subroutine to display one-line summary of hunks.
This commit implements a rather simple-minded mechanism
to display a one-line summary of the hunks in an array ref.
The display consists of the line numbers and the first
changed line, truncated to 80 characters. 20 lines are
displayed at a time, and the index of the first undisplayed
line is returned, allowing the caller to display more if
desired. (The 20 and 80 should be made configurable.)
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
changes from v1:
do not print '@@' characters in summary
pad line numbers in summary to 20 chars to help alignment
only accept diff lines with a non-space, non-bracket character
ensure a newline appears on a trimmed line
changes from v2:
accept any line with a word char (instead of insisting on non-bracket)
use "$i || = 0" instead of "$i = 0 if not $i"
git-add--interactive.perl | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..eb11132 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -836,6 +836,47 @@ sub patch_update_cmd {
}
}
+# Generate a one line summary of a hunk.
+sub summarize_hunk {
+ my $rhunk = shift;
+ my $summary = $rhunk->{TEXT}[0];
+
+ # Keep the line numbers, discard extra context.
+ $summary =~ s/@@(.*?)@@.*/$1 /s;
+ $summary .= " " x (20 - length $summary);
+
+ # Add some user context.
+ for my $line (@{$rhunk->{TEXT}}) {
+ if ($line =~ m/^[+-].*\w/) {
+ $summary .= $line;
+ last;
+ }
+ }
+
+ chomp $summary;
+ return substr($summary, 0, 80) . "\n";
+}
+
+
+# Print a one-line summary of each hunk in the array ref in
+# the first argument, starting wih the index in the 2nd.
+sub display_hunks {
+ my ($hunks, $i) = @_;
+ my $ctr = 0;
+ $i ||= 0;
+ for (; $i < @$hunks && $ctr < 20; $i++, $ctr++) {
+ my $status = " ";
+ if (defined $hunks->[$i]{USE}) {
+ $status = $hunks->[$i]{USE} ? "+" : "-";
+ }
+ printf "%s%2d: %s",
+ $status,
+ $i + 1,
+ summarize_hunk($hunks->[$i]);
+ }
+ return $i;
+}
+
sub patch_update_file {
my ($ix, $num);
my $path = shift;
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* git-gui: Warn when username and e-mail address is unconfigured?
From: Peter Krefting @ 2008-12-04 10:43 UTC (permalink / raw)
To: Git Mailing List
Hi!
When using Git on Windows, it doesn't pick up a user name from the
environment, which leads to commits made by git gui (and probably by
git itself) to show up as being made by "unknown <username@.(none)>"
(where "username" is the Windows account name).
Is it possible to add a warning to git-gui the first time a commit is
attempted if the e-mail address is not configured, and have the user
open the configuration dialogue to set up the name properly?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: more merge strategies : feature request
From: Nanako Shiraishi @ 2008-12-04 10:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Leo Razoumov, Caleb Cushing, git
In-Reply-To: <7vabbc7kk5.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> I thought http://article.gmane.org/gmane.comp.version-control.git/89033 in
> the thread (and your response to it which is 89175) pretty much concluded
> the discussion. Is Caleb adding anything new to the discussion (iow, is
> there a convincing new argument why having such a merge is a good idea and
> what the workflow looks like that benefits from it)?
I first thought so, but after reading this feature request thread again I do not think so anymore.
Sorry for the noise.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: read-only mode
From: Michael J Gruber @ 2008-12-04 9:47 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <8763m0swtz.fsf@jidanni.org>
jidanni@jidanni.org venit, vidit, dixit 03.12.2008 23:44:
> Here's a documentation stub. Please fix and finish it and place in some manual.
[Warning: irony ahead] Yes master, at your service!
[I'm aware he tone in the quote above may be due to translation issues.]
> ==Using git in read-only mode==
> Let's say you just want to examine things. There is a fine line
> between commands and options that just examine things vs. those that
> change things. One might worry that they can't remember that fine line.
>
> Therefore the safest way to ensure you are using git in 'read-only mode' is to
> * su nobody, or
> * chmod -R u-w . (and remember to chmod -R u+w when you are finished), or
This does change things (time stamps).
I'd say the two above are no git-specific suggestions at all, and "cp -a
.git .git-orig" is the best safety-net for the cautious (assuming a
clean working tree) when doing heavy work but overkill for inspection.
> * ???
* clone and inspect the clone instead
* use obvious read-only commands (status, log, diff, show, ls-files,
tag&branch without argument) and avoid obvious write commands (commit,
checkout, apply, ...)
Without specifying "things" any further (repo, objects, index, working
tree) I don't really understand what the problem is.
Michael
^ permalink raw reply
* Re: [StGit PATCH] Print conflict details with the new infrastructure (bug #11181)
From: Karl Hasselström @ 2008-12-04 9:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081203213813.9924.62751.stgit@localhost.localdomain>
On 2008-12-03 21:38:13 +0000, Catalin Marinas wrote:
> The patch modifies the IndexAndWorkTree.merge() function to display
> pass the conflict information (files) when raising an exception. The
> logic is similar to the one in the old infrastructure.
Looks good. Thanks.
> Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 2/2]
From: Junio C Hamano @ 2008-12-04 9:00 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <49377F25.9020005@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> From b039fb8aa03efab3faf46c0a0a8d84cea974f26f Mon Sep 17 00:00:00 2001
> From: William Pursell <bill.pursell@gmail.com>
> Date: Thu, 4 Dec 2008 06:48:57 +0000
> Subject: [PATCH 2/2] Add 'g' command to go to a hunk.
>
> When a minor change is made while the working directory
> is in a bit of a mess (and the user should have done a
> stash before making the minor edit, but didn't) it is
> somewhat difficult to wade through all of the hunks using
> git add --patch. This allows one to jump to the hunk
> that needs to be staged without having to respond 'n' to
> each preceding hunk.
The issue is not limited to "forgot to stash" situation.
> Signed-off-by: William Pursell <bill.pursell@gmail.com>
> ---
It is customary to explain what you changed since v1 here, after the
three-dash separator, to help reviewers.
> git-add--interactive.perl | 26 ++++++++++++++++++++++++++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index b25a841..555c981 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -800,6 +800,7 @@ y - stage this hunk
> n - do not stage this hunk
> a - stage this and all the remaining hunks in the file
> d - do not stage this hunk nor any of the remaining hunks in the file
> +g - select a hunk to goto
"go to"? There are a few more.
> j - leave this hunk undecided, see next undecided hunk
> J - leave this hunk undecided, see next hunk
> k - leave this hunk undecided, see previous undecided hunk
> @@ -946,6 +947,9 @@ sub patch_update_file {
> if ($ix < $num - 1) {
> $other .= '/J';
> }
> + if ($num > 1) {
> + $other .= '/g';
> + }
> for ($i = 0; $i < $num; $i++) {
> if (!defined $hunk[$i]{USE}) {
> $undecided = 1;
> @@ -979,6 +983,28 @@ sub patch_update_file {
> }
> next;
> }
> + elsif ($other =~ 'g' && $line =~ /^g(.*)/) {
I think I fixed this with ($other =~ /g/ && ...) when I queued your
previous round to 'pu' tonight.
> + my $response = $1;
> + my $i = $ix > 10 ? $ix - 10 : 0;
This is different from v1. I understand the motivation (i.e. if you are
at 73rd hunk of a 100-hunk series, showing hunks 63-83 instead of starting
from hunk 1-10 would be nicer), but that is something to explain as one of
the "changes since v1".
I think you are inside a loop that is controlled by another $i (see the
context in the hunk before this one) and it would be better to use
different variable, such as $hunk_no (or just $no).
> + while ($response eq '') {
> + my $extra = "";
> + $i = display_hunks(\@hunk, $i);
> + if ($i < $num) {
> + $extra = " (<ret> to see more)";
> + }
> + print "goto which hunk$extra? ";
"go to"?
Again, this came too late for tonight's round. I've parked your previous
one with fix-up in 'pu', but you are free to tell me to replace it
(together with [1/2] from your previous round) with an updated pair.
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 1/2]
From: Junio C Hamano @ 2008-12-04 8:47 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <49377ED8.4050905@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
>> How well does substr() work with utf-8 and other multi-byte encodings
>> these days, I have to wonder...
>
> Hopefully, it works well.
"Hopefully" is the last word I'd like to hear from submitters. It would
be either "I do not know" or "I studied the topic and I know the code works".
> Here's another go, with your suggestions applied.
Sorry, this came too late for tonight's round. I have a fixed-up one
based on your previous round parked in 'pu', which I'll be replacing with
this one (or your future re-submission if there is any) later in the week.
By the way, I noticed that you are sending your patches with:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Please don't. format=flawed tends to destroy whitespaces (I fixed them up
by hand for the ones I parked in 'pu').
> + # Add some user context, the first changed line that contains
> + # some non-white character other than a bracket.
> + for my $line (@{$rhunk->{TEXT}}) {
> + if ($line =~ m/^([+-][][{}()\s]*[^][{}()\s])/) {
I would say "$line =~ /^[-+].*\w/" (i.e. match any +/- line that contains
a word letter) would be sufficient, and it would be much easier to read.
As you append the entire $line to $summary, there is no need to capture
with ().
> +# Print a one-line summary of each hunk in the array ref in
> +# the first argument, starting wih the index in the 2nd.
> +sub display_hunks {
> + my ($hunks, $i) = @_;
> + my $ctr = 0;
> + $i = 0 if not $i;
I think "$i ||= 0" is more customary.
^ permalink raw reply
* Re: [RFCv3 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-04 7:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <200812040249.01374.jnareb@gmail.com>
On Thu, Dec 4, 2008 at 2:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, Dec 4, 2008 at 01:20, Giuseppe Bilotta wrote:
>> On Thu, Dec 4, 2008 at 12:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>>> +
>>>> + # The maximum number of patches in a patchset generated in patch
>>>> + # view. Set this to 0 or undef to disable patch view, or to a
>>>> + # negative number to remove any limit.
>>>> + 'patches' => {
>>>> + 'override' => 1,
>>>> + 'default' => [16]},
>
> Errr... you need something like 'sub' => \&feature_patches for override
> to actually work, I think.
Oops, right.
>> I always assumed that the disabled default was related to how invasive
>> the changes would be (to the UI or computationally-wise). As for the
>> overridability, that's actually the only reason why it would make
>> sense to put in the %feature hash ... otherwise a conf-settable
>> $patch_max (as in v2) would have been enough.
>
> Add to that the fact that this patch just adds the new view, like for
> example in the case of 'snapshot' link, which was turned on... but fact,
> it was by default not overridable. I would agree that it can be turned
> on with low limit but not overridable in introductory patch.
Ok, I'll make it non-overridable, and keep this 16 limit for starters.
Or would you suggest even lower?
>>>> sub git_commitdiff {
>>>> my $format = shift || 'html';
>>>> +
>>>> + my $patch_max = gitweb_check_feature('patches');
>>>> + if ($format eq 'patch') {
>>>> + die_error(403, "Patch view not allowed") unless $patch_max;
>>>> + }
>>>> +
>>>
>>> Should you have to pay overhead for the check-feature call even when
>>> the $format is not "patch"?
>>
>> Actually I wasn't sure if I could use my within the if block, and have
>> the value visible outside (it's used further down when picking the
>> options to pass to format-patch). And since it was used in the second
>> patch anyway to choose whether to add the 'patch' link in html view or
>> not, I just put it outside the block.
>
> You have to use _declaration_ ourside block, but assignment can happen
> inside:
>
> + my $patch_max;
> + if ($format eq 'patch') {
> + $patch_max = gitweb_check_feature('patches');
> + die_error(403, "Patch view not allowed") unless $patch_max;
> + }
Right, stupid me.
> (Side note: doesn't it uses spaces instead of tabs for align?)
I'll check.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 2/2]
From: William Pursell @ 2008-12-04 6:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4p1kalno.fsf@gitster.siamese.dyndns.org>
From b039fb8aa03efab3faf46c0a0a8d84cea974f26f Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Thu, 4 Dec 2008 06:48:57 +0000
Subject: [PATCH 2/2] Add 'g' command to go to a hunk.
When a minor change is made while the working directory
is in a bit of a mess (and the user should have done a
stash before making the minor edit, but didn't) it is
somewhat difficult to wade through all of the hunks using
git add --patch. This allows one to jump to the hunk
that needs to be staged without having to respond 'n' to
each preceding hunk.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b25a841..555c981 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -800,6 +800,7 @@ y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
+g - select a hunk to goto
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
@@ -946,6 +947,9 @@ sub patch_update_file {
if ($ix < $num - 1) {
$other .= '/J';
}
+ if ($num > 1) {
+ $other .= '/g';
+ }
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$undecided = 1;
@@ -979,6 +983,28 @@ sub patch_update_file {
}
next;
}
+ elsif ($other =~ 'g' && $line =~ /^g(.*)/) {
+ my $response = $1;
+ my $i = $ix > 10 ? $ix - 10 : 0;
+ while ($response eq '') {
+ my $extra = "";
+ $i = display_hunks(\@hunk, $i);
+ if ($i < $num) {
+ $extra = " (<ret> to see more)";
+ }
+ print "goto which hunk$extra? ";
+ $response = <STDIN>;
+ chomp $response;
+ }
+ if ($response !~ /^\s*\d+\s*$/) {
+ print STDERR "Invalid number: '$response'\n";
+ } elsif (0 < $response && $response <= $num) {
+ $ix = $response - 1;
+ } else {
+ print STDERR "Sorry, only $num hunks available.\n";
+ }
+ next;
+ }
elsif ($line =~ /^d/i) {
while ($ix < $num) {
if (!defined $hunk[$ix]{USE}) {
--
1.6.1.rc1.37.g83daf.dirty
^ permalink raw reply related
* Re: summaries in git add --patch[PATCH 1/2]
From: William Pursell @ 2008-12-04 6:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4g8alp7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Do you really want the surrounding @@ in the result, by the way?
Oddly, I liked it before. But now that you mention it, it does
seem ugly.
> How well does substr() work with utf-8 and other multi-byte encodings
> these days, I have to wonder...
Hopefully, it works well.
Here's another go, with your suggestions applied.
From 92ab9b7c694ba98b43984bbbdfcd5eeb9cbb7d56 Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Thu, 4 Dec 2008 06:09:50 +0000
Subject: [PATCH 1/2] Add subroutine to display one-line summary of hunks.
This commit implements a rather simple-minded mechanism
to display a one-line summary of the hunks in an array ref.
The display consists of the line numbers and the first
changed line, truncated to 80 characters. 20 lines are
displayed at a time, and the index of the first undisplayed
line is returned, allowing the caller to display more if
desired. (The 20 and 80 should be made configurable.)
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 42 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..b25a841 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -836,6 +836,48 @@ sub patch_update_cmd {
}
}
+# Generate a one line summary of a hunk.
+sub summarize_hunk {
+ my $rhunk = shift;
+ my $summary = $rhunk->{TEXT}[0];
+
+ # Keep the line numbers, discard extra context.
+ $summary =~ s/@@(.*?)@@.*/$1 /s;
+ $summary .= " " x (20 - length $summary);
+
+ # Add some user context, the first changed line that contains
+ # some non-white character other than a bracket.
+ for my $line (@{$rhunk->{TEXT}}) {
+ if ($line =~ m/^([+-][][{}()\s]*[^][{}()\s])/) {
+ $summary .= $line;
+ last;
+ }
+ }
+
+ chomp $summary;
+ return substr($summary, 0, 80) . "\n";
+}
+
+
+# Print a one-line summary of each hunk in the array ref in
+# the first argument, starting wih the index in the 2nd.
+sub display_hunks {
+ my ($hunks, $i) = @_;
+ my $ctr = 0;
+ $i = 0 if not $i;
+ for (; $i < @$hunks && $ctr < 20; $i++, $ctr++) {
+ my $status = " ";
+ if (defined $hunks->[$i]{USE}) {
+ $status = $hunks->[$i]{USE} ? "+" : "-";
+ }
+ printf "%s%2d: %s",
+ $status,
+ $i + 1,
+ summarize_hunk($hunks->[$i]);
+ }
+ return $i;
+}
+
sub patch_update_file {
my ($ix, $num);
my $path = shift;
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* Re: "git help stage" doesn't display git-stage man page
From: Jeff King @ 2008-12-04 3:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Teemu Likonen, git, Scott Chacon
In-Reply-To: <7vmyfdfyi9.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 03, 2008 at 12:34:22AM -0800, Junio C Hamano wrote:
> diff --git a/Makefile b/Makefile
> index 9577d6f..5158197 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -320,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
> BUILT_INS += git-peek-remote$X
> BUILT_INS += git-repo-config$X
> BUILT_INS += git-show$X
> +BUILT_INS += git-stage$X
> BUILT_INS += git-status$X
> BUILT_INS += git-whatchanged$X
We need this, too, then.
-- >8 --
add stage to gitignore
This is a generated builtin since 24b1f65f (Install git-stage in
exec-path).
Signed-off-by: Jeff King <peff@peff.net>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 0c35577..327e660 100644
--- a/.gitignore
+++ b/.gitignore
@@ -118,6 +118,7 @@ git-show
git-show-branch
git-show-index
git-show-ref
+git-stage
git-stash
git-status
git-stripspace
--
1.6.1.rc1.309.g51074
^ permalink raw reply related
* Re: How to update the tag to Git server?
From: Junio C Hamano @ 2008-12-04 2:48 UTC (permalink / raw)
To: garyyang6; +Cc: git
In-Reply-To: <84437.20577.qm@web37903.mail.mud.yahoo.com>
Gary Yang <garyyang6@yahoo.com> writes:
> I pushed code from my local repository to Git Server.
> git push git.company.com:/pub/git/training.git
>
> I, then tagged my local repository.
> git tag -u gyang@company.com RELEASE_2
git-push(1) manual page says that the syntax of the command is:
'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-v | --verbose]
[<repository> <refspec>...]
and its OPTIONS section explains what <refspec> means.
<refspec>...::
The canonical format of a <refspec> parameter is
`+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
...
The <src> side represents the source branch (or arbitrary
"SHA1 expression", such as `master~4` (four parents before the
tip of `master` branch); see linkgit:git-rev-parse[1]) that you
want to push. The <dst> side represents the destination location.
You want to update refs/tags/RELEASE_2 on the destination side (i.e. the
public server) with the same refs/tags/RELEASE_2 on the source side
(i.e. your side), so you would want to say
refs/tags/RELEASE_2:refs/tags/RELEASE_2
for <refspec>. The documentation further mentions that there is a
short-hand for that:
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
Hence the command line becomes:
$ git push svdcgit01.amcc.com:/pub/git/training.git tag RELEASE_2
Note that saying "tag" is redundant these days as long as you do not have
a branch named "RELEASE_2" at the same time. But saying "tag" never
hurts, as it is still (and will be) supported.
Note to people who teach git to new people. The moral of the story is not
that people should learn to read the manual pages. It is that people
should not learn "push" without remote nor refspec first. In other words,
the first push command you teach them should be the "git push $over_there
$this_refspec" form, fully spelled.
^ permalink raw reply
* Re: How to update the tag to Git server?
From: Peter Harris @ 2008-12-04 2:35 UTC (permalink / raw)
To: garyyang6; +Cc: git
In-Reply-To: <84437.20577.qm@web37903.mail.mud.yahoo.com>
On Wed, Dec 3, 2008 at 9:16 PM, Gary Yang wrote:
>
> I pushed code from my local repository to Git Server.
> git push git.company.com:/pub/git/training.git
>
> I, then tagged my local repository.
> git tag -u gyang@company.com RELEASE_2
>
> I want to update the Git server so that I can have the tag at my Git server, I did:
> git push git.company.com:/pub/git/training.git
> Everything up-to-date
Did you try "git push git.company.com:/pub/git/training.git tag
RELEASE_2" or "git push git.company.com:/pub/git/training.git --tags",
as it suggests in "git help push"?
Peter Harris
^ permalink raw reply
* How to update the tag to Git server?
From: Gary Yang @ 2008-12-04 2:16 UTC (permalink / raw)
To: git
I pushed code from my local repository to Git Server.
git push git.company.com:/pub/git/training.git
I, then tagged my local repository.
git tag -u gyang@company.com RELEASE_2
I want to update the Git server so that I can have the tag at my Git server, I did:
git push git.company.com:/pub/git/training.git
Everything up-to-date
I got "Everything up-to-date". Same story for the command with -f.
git push -f svdcgit01.amcc.com:/pub/git/training.git
git tag -l
RELEASE_2
>From my git server, git.company.com, I cannot see the tag at summary. I need to have the tag, RELEASE_2 at git.company.com. Can someone tell me how to do it?
Thanks.
^ 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