* Re: [PATCH 0/6] echo usernames as they are typed
From: Erik Faye-Lund @ 2011-11-28 9:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111128035321.GA15640@sigill.intra.peff.net>
On Mon, Nov 28, 2011 at 4:53 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 27, 2011 at 10:17:26AM +0100, Erik Faye-Lund wrote:
>
>> > And here's something I've been meaning to do on top: actually echo
>> > characters at the username prompt. We can't do this portably, but we can
>> > at least stub out a compatibility layer and let each system do something
>> > sensible.
>>
>> Interesting, I've been working on something pretty similar: getting
>> rid of getpass usage all together:
>>
>> https://github.com/kusma/git/tree/work/askpass
>>
>> My reason to write a getpass replacement was to avoid capping input to
>> PASS_MAX, which can be as low as 8 characters (and AFAIK is just that
>> on Solaris)...
>
> Yeah, if there are really bad getpass implementations, we would want to
> work around them. If we are going to do so, it might make sense to
> combine the effort with my getpass_echo wrapper, as they are really the
> same function, modulo tweaking the echo settings.
>
My thinking exactly ;)
> It would also be nice to make getpass a little more predictable. If
> /dev/tty can't be opened, glibc's getpass will fall back to writing the
> prompt to stderr and reading the password from stdin. But we definitely
> don't want to do that in git-remote-curl, where stdin is already talking
> a special protocol with the parent fetch process.
>
> So I think it might be best to just write our own getpass. However,
> your implementation looks wrong to me:
>
It probably is, yes. It was a very naive attempt ;)
>> diff --git a/password.c b/password.c
>> new file mode 100644
>> index 0000000..727ed84
>> --- /dev/null
>> +++ b/password.c
>> @@ -0,0 +1,94 @@
>> +#include "cache.h"
>> +#include "git-compat-util.h"
>> +#include "strbuf.h"
>> +#include "run-command.h"
>> +
>> +#ifndef WIN32
>> +
>> +static void ask_password(struct strbuf *sb, const char *prompt)
>> +{
>> + struct termios attr;
>> + tcflag_t c_lflag;
>> +
>> + if (tcgetattr(1, &attr) < 0)
>> + die("tcgetattr failed!");
>> + c_lflag = attr.c_lflag;
>
> This is getting the terminal attributes for stdout. But in many
> cases, stdout will not be connected to the terminal (in particular,
> remote-curl, as I mentioned above, will have its stdio connected to the
> parent fetch process). Stderr is a better guess, as you do here:
>
>> + fputs(prompt, stderr);
>
> but even that is not foolproof. With getpass(), this should work:
>
> git clone ... 2>errors
>
> with the prompt going to the terminal. But it doesn't with your patch.
>
> You really want to open "/dev/tty" on most Unix systems (which is what
> getpass() does).
Yes, you're right. Opening "/dev/tty" is much better. But what happens
for processes started by GUI applications (with no easily observable
tty, if any)? Does open simply fail? If so, is it desirable for us to
fail in that case?
> I have no idea what would be appropriate on Windows.
>
It's pretty similar, but not exactly: CreateFile("CONIN$", ...) or
CreateFile("CONOUT$", ...), depending on if you want the read-handle
or the write-handle... I can probably cook up something a bit more
concrete, though.
But _getch() that we already use always reads from the console
(according to MSDN, I haven't actually tested this myself:
http://msdn.microsoft.com/en-us/library/078sfkak%28v=VS.80%29.aspx).
But I don't think this allows us to fail when no console is attached.
Question is, should we fail in such cases? Windows does have an API to
prompt for passwords in a GUI window... Perhaps fallbacking to those
are the way to go? Something like:
if (GetConsoleWindow()) {
/* normal console-stuff */
} else {
/* call CredUIPromptForWindowsCredentials(...) instead */
}
This might be nicer towards GUI tools, but it requires us to
explicitly ask for a password (and possibly a username at the same
time)...
>> + for (;;) {
>> + int c = getchar();
>> + if (c == EOF || c == '\n')
>> + break;
>> + strbuf_addch(sb, c);
>> + }
>
> And this is even worse. You're reading from stdin, which will get
> whatever cruft is in the pipe coming from the parent process (or may
> even cause a hang, as the parent is probably blocking waiting to read
> from the child helper).
>
Yeah, thanks for pointing these glitches out ;)
^ permalink raw reply
* Re: Switch from svn to git and modify repo completely
From: Matthias Fechner @ 2011-11-28 10:10 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Alexey Shumkin
In-Reply-To: <4ED21756.70705@fechner.net>
Am 27.11.11 11:56, schrieb Matthias Fechner:
> git clone gitrepo.git tofilter.git
one additional note.
To get it really working you should execute:
git clone file://gitrepo.git tofilter.git
And later if you copy it to a bare repo:
git clone --bare file://tofiler.git barerepo.git
This will ensure that removed files are not in the cloned repository.
Bye,
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Is there a "--follow" equvalent argument to git-rev-list?
From: Steinar Bang @ 2011-11-28 10:37 UTC (permalink / raw)
To: git
I'm trying to make emacs vc log (`C-x v l') show the full history of git
versioned files.
In my first attempt, I tried adding a "--follow" argument to "git log"
in the vc-git-print-log message. This made `C-x v l' show the full log.
But the problem with this solution was that commands done from the log,
such as diffing (a very convenient way to do diffs, when the "version
numbers" are sha1 hashes...), showing a particular revision, or
annotating from that revision and back, didn't work. See the comment at
the end of this bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
Today I decided to take another peek at this, but vc-git.el in the emacs
23.1 version of the file, now uses "git rev-list" instead of "git log"
to get the revision list.
And "git rev-list" doesn't seem to have anything similar to
"--follow"...? At least I haven't found it.
The man page doesn't contain the text "renam".
Guessing at what the man page has meant, I've tried adding the "--all"
and "--full-history" arguments, but `C-x v l' still only shows history
back to the last move.
Is there an argument to "git rev-list" that will make it track across
renames? Or is this only possible with "git log --follow"?
Thanks!
- Steinar
^ permalink raw reply
* Re: Infinite loop in cascade_filter_fn()
From: Carlos Martín Nieto @ 2011-11-28 10:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Henrik Grubbström, Git Mailing list
In-Reply-To: <7vy5v2wleb.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 4081 bytes --]
On Sat, Nov 26, 2011 at 02:48:12PM -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > diff --git a/convert.c b/convert.c
> > index 86e9c29..c050b86 100644
> > --- a/convert.c
> > +++ b/convert.c
> > @@ -880,20 +880,29 @@ static int lf_to_crlf_filter_fn(struct stream_filter *filter,
> > const char *input, size_t *isize_p,
> > char *output, size_t *osize_p)
> > {
> > - size_t count;
> > + size_t count, o = 0;
> > + static int want_lf = 0;
>
> I do not think we want function scope static state anywhere in the cascade
> filter chain, as it will forbid us from running more than one output chain
> at the same time in the future. I think the correct way to structure it
> would be to create lf_to_crlf_filter as a proper subclass of stream_filter
> (see how cascade_filter_fn() casts its filter argument down to an instance
> of the cascade_filter class and uses it to keep track of its state) and
> keep this variable as its own filter state [*1*].
Good point, here's a patch that does that.
cmn
--- 8< ---
Subject: [PATCHv2] convert: track state in LF-to-CRLF filter
There may not be enough space to store CRLF in the output. If we don't
fill the buffer, then the filter will keep getting called with the same
short buffer and will loop forever.
Instead, always store the CR and record whether there's a missing LF
if so we store it in the output buffer the next time the function gets
called.
Reported-by: Henrik Grubbström <grubba@roxen.com>
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
convert.c | 50 +++++++++++++++++++++++++++++++++++++-------------
1 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/convert.c b/convert.c
index 86e9c29..1c91409 100644
--- a/convert.c
+++ b/convert.c
@@ -876,24 +876,39 @@ int is_null_stream_filter(struct stream_filter *filter)
/*
* LF-to-CRLF filter
*/
+
+struct lf_to_crlf_filter {
+ struct stream_filter filter;
+ int want_lf;
+};
+
static int lf_to_crlf_filter_fn(struct stream_filter *filter,
const char *input, size_t *isize_p,
char *output, size_t *osize_p)
{
- size_t count;
+ size_t count, o = 0;
+ struct lf_to_crlf_filter *lfcrlf = (struct lf_to_crlf_filter *) filter;
+
+ /* Output a pending LF if we need to */
+ if (lfcrlf->want_lf) {
+ output[o++] = '\n';
+ lfcrlf->want_lf = 0;
+ }
if (!input)
- return 0; /* we do not keep any states */
+ return 0; /* We've already dealt with the state */
+
count = *isize_p;
if (count) {
- size_t i, o;
- for (i = o = 0; o < *osize_p && i < count; i++) {
+ size_t i;
+ for (i = 0; o < *osize_p && i < count; i++) {
char ch = input[i];
if (ch == '\n') {
- if (o + 1 < *osize_p)
- output[o++] = '\r';
- else
- break;
+ output[o++] = '\r';
+ if (o >= *osize_p) {
+ lfcrlf->want_lf = 1;
+ continue; /* We need to increase i */
+ }
}
output[o++] = ch;
}
@@ -904,15 +919,24 @@ static int lf_to_crlf_filter_fn(struct stream_filter *filter,
return 0;
}
+static void lf_to_crlf_free_fn(struct stream_filter *filter)
+{
+ free(filter);
+}
+
static struct stream_filter_vtbl lf_to_crlf_vtbl = {
lf_to_crlf_filter_fn,
- null_free_fn,
+ lf_to_crlf_free_fn,
};
-static struct stream_filter lf_to_crlf_filter_singleton = {
- &lf_to_crlf_vtbl,
-};
+static struct stream_filter *lf_to_crlf_filter(void)
+{
+ struct lf_to_crlf_filter *lfcrlf = xmalloc(sizeof(*lfcrlf));
+ lfcrlf->filter.vtbl = &lf_to_crlf_vtbl;
+ lfcrlf->want_lf = 0;
+ return (struct stream_filter *)lfcrlf;
+}
/*
* Cascade filter
@@ -1194,7 +1218,7 @@ struct stream_filter *get_stream_filter(const char *path, const unsigned char *s
else if (output_eol(crlf_action) == EOL_CRLF &&
!(crlf_action == CRLF_AUTO || crlf_action == CRLF_GUESS))
- filter = cascade_filter(filter, &lf_to_crlf_filter_singleton);
+ filter = cascade_filter(filter, lf_to_crlf_filter());
return filter;
}
--
1.7.8.rc3.31.g017d1
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply related
* Re: [BUG] difftool falls back to normal diff when used during merge resolution
From: David Aguilar @ 2011-11-28 11:16 UTC (permalink / raw)
To: Jakub Turski; +Cc: git@vger.kernel.org
In-Reply-To: <CAHWJSOSB768hWsNqrR559wef3-k_yZ=TjS_mxfj3TxXdgwm5iQ@mail.gmail.com>
On Nov 27, 2011, at 10:09 AM, Jakub Turski <yacoob@gmail.com> wrote:
> Hello there,
>
> Just found this behavior, and after a chat on IRC it looks to me like
> an actual bug. I have 'git difftool' configured to use vimdiff - and
> it worked fine. Despite that config, git still falls back to plain
> diff when I launch difftool mid-way through merge conflict resolution.
>
> Here's a reproducable testcase (w/ version 1.7.7.3)
>
> $ mkdir a; cd a; git init; echo A>A; git add A; git commit -m A; git
> branch alt; echo AA>A; git commit -am AA; git checkout alt; echo B>A;
> git commit -m B; git commit -am B; git checkout master; git merge alt;
> git difftool -t vimdiff A
>
> Results:
> http://pastie.org/2929336
I think this is an unfortunate case where the implementation leaks
into the user experience.
I haven't checked, but I'm pretty sure this is because
GIT_EXTERNAL_DIFF has no affect when the conflicts exist.
git mergetool can be used in this situation.
We could do a check up front in difftool to see whether conflicts
exist and exit with an error message. The difftool script is quite
small and basically a very thin wrapper around git diff, though, so I
do hesitate before making it more complicated.
anyways, try "git mergetool".
--
David
^ permalink raw reply
* Re: [PATCH 0/6] echo usernames as they are typed
From: Jeff King @ 2011-11-28 11:31 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <CABPQNSbLvWh-ivaqBk-Du+kwZvV3t+ajEJhHATRzyGZbHYyM=Q@mail.gmail.com>
On Mon, Nov 28, 2011 at 10:36:21AM +0100, Erik Faye-Lund wrote:
> > You really want to open "/dev/tty" on most Unix systems (which is what
> > getpass() does).
>
> Yes, you're right. Opening "/dev/tty" is much better. But what happens
> for processes started by GUI applications (with no easily observable
> tty, if any)? Does open simply fail? If so, is it desirable for us to
> fail in that case?
Yes, the open will fail (on Linux, I get ENXIO).
And yes, we should fail in that case. getpass() will generally return
NULL in that instance, and the current implementation of git_getpass()
will die(), explaining that we could not get the password.
> > I have no idea what would be appropriate on Windows.
>
> It's pretty similar, but not exactly: CreateFile("CONIN$", ...) or
> CreateFile("CONOUT$", ...), depending on if you want the read-handle
> or the write-handle... I can probably cook up something a bit more
> concrete, though.
OK, that maps to the /dev/tty concept quite well. Though I suspect the
code for turning off character echo-ing is going to also be different.
> But _getch() that we already use always reads from the console
> (according to MSDN, I haven't actually tested this myself:
> http://msdn.microsoft.com/en-us/library/078sfkak%28v=VS.80%29.aspx).
> But I don't think this allows us to fail when no console is attached.
> Question is, should we fail in such cases? Windows does have an API to
> prompt for passwords in a GUI window... Perhaps fallbacking to those
> are the way to go? Something like:
>
> if (GetConsoleWindow()) {
> /* normal console-stuff */
> } else {
> /* call CredUIPromptForWindowsCredentials(...) instead */
> }
Certainly on non-Windows something like that would not be welcome. The
user can already have specified GIT_ASKPASS if they don't have a
terminal. And once the credential-helper code is in, they can use a
platform-specific helper that provides a nice dialog if they want it.
So I would say trying to do something graphical would be surprising and
unwelcome. But then, I am a very Unix-y kind of guy. Maybe on Windows
something like that would be more favorable. I'll leave that decision to
people who know more.
-Peff
^ permalink raw reply
* Re: [PATCH 0/6] echo usernames as they are typed
From: Frans Klaver @ 2011-11-28 11:49 UTC (permalink / raw)
To: Jeff King; +Cc: Erik Faye-Lund, git
In-Reply-To: <20111128113127.GA23408@sigill.intra.peff.net>
On Mon, Nov 28, 2011 at 12:31 PM, Jeff King <peff@peff.net> wrote:
> Certainly on non-Windows something like that would not be welcome. The
> user can already have specified GIT_ASKPASS if they don't have a
> terminal. And once the credential-helper code is in, they can use a
> platform-specific helper that provides a nice dialog if they want it.
>
> So I would say trying to do something graphical would be surprising and
> unwelcome. But then, I am a very Unix-y kind of guy. Maybe on Windows
> something like that would be more favorable. I'll leave that decision to
> people who know more.
I would say that also on windows it would be surprising if you are
working on the command line and suddenly a pop-up appears asking for
input. So even on windows you should probably keep away from gui stuff
in a cli tool, although there are tools that don't.
Frans
^ permalink raw reply
* Re: [PATCH 0/6] echo usernames as they are typed
From: Erik Faye-Lund @ 2011-11-28 12:59 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111128113127.GA23408@sigill.intra.peff.net>
On Mon, Nov 28, 2011 at 12:31 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 28, 2011 at 10:36:21AM +0100, Erik Faye-Lund wrote:
>
>> > You really want to open "/dev/tty" on most Unix systems (which is what
>> > getpass() does).
>>
>> Yes, you're right. Opening "/dev/tty" is much better. But what happens
>> for processes started by GUI applications (with no easily observable
>> tty, if any)? Does open simply fail? If so, is it desirable for us to
>> fail in that case?
>
> Yes, the open will fail (on Linux, I get ENXIO).
>
> And yes, we should fail in that case. getpass() will generally return
> NULL in that instance, and the current implementation of git_getpass()
> will die(), explaining that we could not get the password.
>
>> > I have no idea what would be appropriate on Windows.
>>
>> It's pretty similar, but not exactly: CreateFile("CONIN$", ...) or
>> CreateFile("CONOUT$", ...), depending on if you want the read-handle
>> or the write-handle... I can probably cook up something a bit more
>> concrete, though.
>
> OK, that maps to the /dev/tty concept quite well. Though I suspect the
> code for turning off character echo-ing is going to also be different.
>
>> But _getch() that we already use always reads from the console
>> (according to MSDN, I haven't actually tested this myself:
>> http://msdn.microsoft.com/en-us/library/078sfkak%28v=VS.80%29.aspx).
>> But I don't think this allows us to fail when no console is attached.
>> Question is, should we fail in such cases? Windows does have an API to
>> prompt for passwords in a GUI window... Perhaps fallbacking to those
>> are the way to go? Something like:
>>
>> if (GetConsoleWindow()) {
>> /* normal console-stuff */
>> } else {
>> /* call CredUIPromptForWindowsCredentials(...) instead */
>> }
>
> Certainly on non-Windows something like that would not be welcome. The
> user can already have specified GIT_ASKPASS if they don't have a
> terminal. And once the credential-helper code is in, they can use a
> platform-specific helper that provides a nice dialog if they want it.
>
Yes, that's certainly cleaner implementation-wise. But didn't you
change it to only do the storage-part in the last round, or did I
misunderstand the updated series?
> So I would say trying to do something graphical would be surprising and
> unwelcome. But then, I am a very Unix-y kind of guy. Maybe on Windows
> something like that would be more favorable. I'll leave that decision to
> people who know more.
Windows doesn't really have that strict norms when it comes to console
applications, but it'd be nice if it didn't do anything obviously
wrong when the GUI isn't available (non-interactive sessions,
PowerShell remote commands, CopSSH, etc). So I guess this is yet
another argument to stay with the credential-helper instead, if
possible...
^ permalink raw reply
* Permissions per git repository
From: pcm2a @ 2011-11-28 13:38 UTC (permalink / raw)
To: git
I have a central git repository running on Windows Server 2008 using Apache
2.2 + Smart HTTP + SSPI (for authentication). I can easily limit users to
all of the repositories with the 'require' command in apache. This is for
all repositories and not just certain ones.
How can I limit user(s) or group(s) to one repository and a different
user(s) or group(s) to another repository using git or apache configuration?
--
View this message in context: http://git.661346.n2.nabble.com/Permissions-per-git-repository-tp7038724p7038724.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Error pushing to remote with git
From: pcm2a @ 2011-11-28 14:15 UTC (permalink / raw)
To: git
I have a fresh Centos 6 server stood up and I have installed git version
1.7.1. I am using the smart http method through apache for access.
When I try to push to the remote server this is what I get:
$ git push origin master
Password:
Counting objects: 6, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (6/6), 436 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
error: unpack failed: index-pack abnormal exit
I have tried these things which made no difference:
* chown -R apache:apache /path/to/git/repository (httpd runs as apache)
* chown -R apache:users /path/to/git/repository
* chmod -R 777 /path/to/git/repository (obviously not secure but wanted to
eliminate this being a file permission problem)
What can I try to get pushing to work?
--
View this message in context: http://git.661346.n2.nabble.com/Error-pushing-to-remote-with-git-tp7038870p7038870.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: two branches: keep one difference but merge others forth and back
From: Carlos Martín Nieto @ 2011-11-28 15:25 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <jats5v$r7c$1@dough.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
On Sun, Nov 27, 2011 at 06:31:42PM +0100, Gelonida N wrote:
> Hi,
>
>
> Is this possible.
>
>
> I'd like to have two branches.
>
> If possible I would be able to merge forth and back between both of them.
>
> However I would like, that certain differences will be kept between both
> branches.
>
> Is there any way to tell git to permanently ignoring certain commits
> from merging?
This goes against what a merge is.
>
>
> Example:
> ---------
> Normally shell scripts would have a first line of
> '#!/bin/bash',
> but in a certain branch I would like that the first lines would be
>
> '#!/usr/local/bin/bash'
>
> All from then on however I'd like to be able to commit on both branches
> and to merge from the other branches (and always keep this difference)
>
> What I tried:
> -------------
> My first naive approach was:
> - create shell scripts in master,
> - create then a branch named 'my_shell'
> - modify first lines of shell scripts in this branch and commit
> - checkout master
> - merge my_shell to master with merge strategy 'ours'
> git pull my_shell -s ours
> - now I changed something else in master
> - when I try to merge back to branch my_shell I will not only get
> the most recent changes done in master, but I will also undo the
> changes in line 1 of my shell scripts.
>
> So it seems I am not doing things as one should.
If you tell git to merge, it expects that you want to take the changes
done in the other branch.
>
>
> Potential other strategies:
> ----------------------------
> - never commit anything on branch my_shell and just pull regularly
> from master to keep it synced.
>
> - commit changes / bug fixes also on branch my_shell, but NEVER merge
> back to master. If a change grom my_shell is really needed on master,
> then just cherry-pick.
>
>
> Thanks in advance for suggestions how you would deal with such 'situations'
You can amend the merge (or the next merge) commit so you undo that
change. Git should leave that line alone as long as you don't change
it.
Or you could have a branch where you make changes and two branches
where you change the hashbang. Merging from the main branch into the
specific branches won't touch the hashbang, as long as you don't touch
it.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Has someone tried to do "git revert <commit> -- <path>"
From: Ævar Arnfjörð Bjarmason @ 2011-11-28 15:46 UTC (permalink / raw)
To: Git Mailing List, Johannes Schindelin
Sometimes I want to partially revert a commit, what I'll do is:
git revert --no-commit <commit> &&
git reset &&
git add <paths> &&
git commit
At which point I'll manually type in the commit window:
Partially revert "description(<commit>)"
This partially reverts <commit>. Only <paths> have been reverted.
Has someone tried to patch the revert logic to just support an
optional paths parameter, in which case this wouldn't need to be so
hard.
^ permalink raw reply
* Re: BUG. git rebase -i successfully continues (and also skips rewording) when pre-commit hook fails (exits with non-zero code)
From: Andrew Wong @ 2011-11-28 16:15 UTC (permalink / raw)
To: git; +Cc: Andrew Wong
In-Reply-To: <20111117125847.190e9b25@ashu.dyn.rarus.ru>
I actually have a patch to fix this sitting in my repo for a while. Thanks for bringing this issue up again.
Andrew Wong (1):
rebase -i: interrupt rebase when "commit --amend" failed during
"reword"
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
--
1.7.8.rc3.32.gb2fac
^ permalink raw reply
* [PATCH] rebase -i: interrupt rebase when "commit --amend" failed during "reword"
From: Andrew Wong @ 2011-11-28 16:15 UTC (permalink / raw)
To: git; +Cc: Andrew Wong
In-Reply-To: <1322496952-23819-1-git-send-email-andrew.kw.w@gmail.com>
"commit --amend" could fail in cases like the user empties the commit
message, or pre-commit failed. When it fails, rebase should be
interrupted, rather than ignoring the error and continue on rebasing.
This gives users a way to gracefully interrupt a "reword" if they
decided they actually want to do an "edit", or even "rebase --abort".
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
---
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 804001b..669f378 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -408,7 +408,8 @@ do_next () {
mark_action_done
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
- git commit --amend --no-post-rewrite
+ git commit --amend --no-post-rewrite ||
+ die_with_patch $sha1 "Cannot amend commit after successfully picking $sha1... $rest"
record_in_rewritten $sha1
;;
edit|e)
--
1.7.8.rc3.32.gb2fac
^ permalink raw reply related
* Git Submodule Problem - Bug?
From: Manuel Koller @ 2011-11-28 17:13 UTC (permalink / raw)
To: git; +Cc: Jens Lehmann, Heiko Voigt
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
Hi
I've encountered strange behavior of git submodule and I cannot think about a way to avoid the problem. I've added a small script that reproduces the problem in the current version of git (1.7.7.3, git-osx-installer).
The problem arises when I pull a commit that switches a submodule with another one and then run git submodule update. Say I have a repo "super" that has one submodule "sub1" in the folder "sub" and a clone "super2". Now I remove the submodule in "super2" and add another one ("sub2") again named "sub", commit this and push it. Now after pulling the commit to "super", I need to run git submodule sync and then git submodule update.
I expect to end up with the submodule "sub2" in sub. But the log clearly shows that the commits from "sub1" are still there (the master branch belongs to "sub1" while origin/master comes from "sub2"). I get the following output:
> ...
> commit 77d8d11fed3b07e1d4e47b3df9fc44c278694a39
> Author: Manuel Koller <koller@stat.math.ethz.ch>
> Date: Mon Nov 28 17:46:45 2011 +0100
>
> initial commit sub1
> commit 346fe6bd9e7957f10c5e833bb1155153379da41c
> Author: Manuel Koller <koller@stat.math.ethz.ch>
> Date: Mon Nov 28 17:46:45 2011 +0100
>
> initial commit sub2
I think it should be twice the same, and "sub2". I checked also with Charon, on his machine, the two log messages reported are "sub1" which completely baffles me.
Best regards,
Manuel
[-- Attachment #2: submodule-bug-minimal-example.bash --]
[-- Type: application/octet-stream, Size: 1491 bytes --]
#/bin/bash
## set -e explicitly
set -e
## set current directory as working directory
wd=`pwd`
## create repositories to be used as submodules
mkdir sub1 sub2 remote
(cd sub1
git init
echo "test sub1" >> file
git add file
git commit -m "initial commit sub1"
)
git clone --bare sub1 remote/sub1.git
(cd sub2
git init
echo "test sub2" >> file
git add file
git commit -m "initial commit sub2"
)
git clone --bare sub2 remote/sub2.git
## create super repository
git init --bare remote/super.git
git clone remote/super.git super
(cd super
git submodule add $wd/remote/sub1.git sub
git commit -m "Added submodule sub1 as sub"
git push -u origin master
)
## clone super repository again
## and switch submodule sub1 by sub2
git clone --recursive remote/super.git super2
(cd super2
## remote submodule sub
git config --remove-section submodule.sub
git rm .gitmodules
rm -rf sub
git rm sub
git commit -m "Removed submodule sub"
## add submodule sub2 as sub
git submodule add $wd/remote/sub2.git sub
git commit -m "Added submodule sub2 as sub"
git push
)
## now pull super
(cd super
git pull
## this will fail
git submodule update --init || echo "submodule update fails, that's ok"
## so sync first und update again
git submodule sync
git submodule update --init
## now sub is corrupt
(cd sub
git log master ## this is from sub1
git log origin/master ## this is from sub2
)
)
^ permalink raw reply
* Re: gitweb: 404 links on some blob pages
From: Jakub Narebski @ 2011-11-28 17:24 UTC (permalink / raw)
To: Jürgen Kreileder; +Cc: git
In-Reply-To: <CAKD0Uuyom0chUGfsh+oBRw8NoH4XutbmkVVKoQon6YO2V5oWkA@mail.gmail.com>
Jürgen Kreileder wrote:
> 2011/11/27 Jakub Narebski <jnareb@gmail.com>:
> > Jürgen Kreileder <jk@blackdown.de> writes:
> >
> > > some blob pages have broken links:
> > >
> > > For example, on
> > > https://git.blackdown.de/?p=contactalbum.git;a=blob;f=Classes/WindowController.m;h=b84d1882cb6c3a2d2058cbdd56b2280b48f1690a;hb=b84d1882cb6c3a2d2058cbdd56b2280b48f1690a
> > > the blob_plain link for WindowController.m leads to '404 - Cannot find file':
> > > https://git.blackdown.de/?p=contactalbum.git;a=blob_plain;f=Classes/WindowController.m;hb=b84d1882cb6c3a2d2058cbdd56b2280b48f1690a
> >
> > That is strange. The check is the same for 'blob' and 'blob_plain'
> > action...
>
> The problem is the missing hash (h) parameter for the latter URL.
> Adding it to the blob_plain link makes it work. Just as removing it
> from the blob link breaks that one as well.
Strange. From the look of the page it looks like the 'hb' ("hash_base")
parameter that should lead to the commit from which we get the file is
bogus.
But the "raw" link uses
href(action=>"blob_plain", -replay=>1)
which means that if 'blob' has "h" set correctly, then 'blob_plain'
should too.
> Adding h=... to the tree link doesn't fix that case, though.
Of course it doesn't if you just copy _blob_ hash as _tree_ hash... :-P
(i.e. if you just copy "h" parameter from 'blob' URL).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Permissions per git repository
From: Jakub Narebski @ 2011-11-28 17:40 UTC (permalink / raw)
To: pcm2a; +Cc: git
In-Reply-To: <1322487502060-7038724.post@n2.nabble.com>
pcm2a <cameron@ree-yees.com> writes:
> I have a central git repository running on Windows Server 2008 using Apache
> 2.2 + Smart HTTP + SSPI (for authentication). I can easily limit users to
> all of the repositories with the 'require' command in apache. This is for
> all repositories and not just certain ones.
>
> How can I limit user(s) or group(s) to one repository and a different
> user(s) or group(s) to another repository using git or apache configuration?
If I remember correctly gitolite (a tool to manage access to git
repositories) has support for controlling access via smart HTTP.
--
Jakub Narębski
^ permalink raw reply
* Copy branch into master
From: Ron Eggler @ 2011-11-28 18:25 UTC (permalink / raw)
To: git
Hi,
Some time ago I created a DVT branch in my project and I have almost been
exclusively working in it. Now the time for some test deployment came and I
didn't have time to merge it all back into the master thus I gave out the
DVT branch version. Now I would like to copy exactly what I have in that
branch back into my master to have an exact copy in my master of what got
deployed with out any changes.
How can I do this?
Please advise.
Thank you!
Ron
--
Ron Eggler
1804 - 1122 Gilford St.
Vancouver, BC
V6G 2P5
(778) 230-9442
^ permalink raw reply
* Re: Copy branch into master
From: Andrew Eikum @ 2011-11-28 18:36 UTC (permalink / raw)
To: Ron Eggler; +Cc: git
In-Reply-To: <CAHxBh_T-f7O4r0zn=NtLTYtdbNqd3qSo2tW84aYRJp7ugDSMpw@mail.gmail.com>
On Mon, Nov 28, 2011 at 10:25:33AM -0800, Ron Eggler wrote:
> Some time ago I created a DVT branch in my project and I have almost been
> exclusively working in it. Now the time for some test deployment came and I
> didn't have time to merge it all back into the master thus I gave out the
> DVT branch version. Now I would like to copy exactly what I have in that
> branch back into my master to have an exact copy in my master of what got
> deployed with out any changes.
> How can I do this?
Couple options, depending on what you want:
Rename DVT to master (similar to 'mv DVT master', including
losing the contents of 'master'):
$ git checkout --detach HEAD
$ git branch -M DVT master
$ git checkout master
Retain old master (like 'mv master old_master; mv DVT master'):
$ git checkout --detach HEAD
$ git branch -m master old_master
$ git branch -m DVT master
$ git checkout master
The "checkout --detach" is just so Git doesn't complain about
moving/deleting the currently checked out branch.
If you haven't yet, be sure to read ProGit, which should make
questions like this trivial for you to answer yourself in the future:
<http://progit.org/book/>
Hope this helps,
Andrew
^ permalink raw reply
* Re: [PATCH 0/6] echo usernames as they are typed
From: Jeff King @ 2011-11-28 18:59 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <CABPQNSYd8PFsoRi6NtjQYNQzM+NHv_aRCLRWQ=XsFuw2gGWAng@mail.gmail.com>
On Mon, Nov 28, 2011 at 01:59:34PM +0100, Erik Faye-Lund wrote:
> > Certainly on non-Windows something like that would not be welcome. The
> > user can already have specified GIT_ASKPASS if they don't have a
> > terminal. And once the credential-helper code is in, they can use a
> > platform-specific helper that provides a nice dialog if they want it.
> >
>
> Yes, that's certainly cleaner implementation-wise. But didn't you
> change it to only do the storage-part in the last round, or did I
> misunderstand the updated series?
Yeah, sorry, I'm getting ahead of myself. I left room in the spec for an
"ask" operation on helpers, but I haven't implemented it yet.
-Peff
^ permalink raw reply
* RE: Copy branch into master
From: Ron Eggler @ 2011-11-28 19:08 UTC (permalink / raw)
To: 'Andrew Eikum'; +Cc: git
In-Reply-To: <20111128183616.GB29503@foghorn.codeweavers.com>
Thanks for that,
I guess I'd go for renaming DVT to master.
However, I also played around with merge a little, started a merge (in
Windows GUI) and aborted it but the icon of my directory keeps showing the
ywellow exclemation mark, signing that a merge is going on right now but
going into the directory, all the files are with a geen check mark. What's
going on here? How do I resolve this - I don't wanna mess things up so I
might rather resolve this before moving DVT to master.
Thanks,
Ron
-----Original Message-----
From: Andrew Eikum [mailto:aeikum@codeweavers.com]
Sent: Monday, November 28, 2011 10:36 AM
To: Ron Eggler
Cc: git@vger.kernel.org
Subject: Re: Copy branch into master
On Mon, Nov 28, 2011 at 10:25:33AM -0800, Ron Eggler wrote:
> Some time ago I created a DVT branch in my project and I have almost been
> exclusively working in it. Now the time for some test deployment came and
I
> didn't have time to merge it all back into the master thus I gave out the
> DVT branch version. Now I would like to copy exactly what I have in that
> branch back into my master to have an exact copy in my master of what got
> deployed with out any changes.
> How can I do this?
Couple options, depending on what you want:
Rename DVT to master (similar to 'mv DVT master', including
losing the contents of 'master'):
$ git checkout --detach HEAD
$ git branch -M DVT master
$ git checkout master
Retain old master (like 'mv master old_master; mv DVT master'):
$ git checkout --detach HEAD
$ git branch -m master old_master
$ git branch -m DVT master
$ git checkout master
The "checkout --detach" is just so Git doesn't complain about
moving/deleting the currently checked out branch.
If you haven't yet, be sure to read ProGit, which should make
questions like this trivial for you to answer yourself in the future:
<http://progit.org/book/>
Hope this helps,
Andrew
^ permalink raw reply
* Re: Infinite loop in cascade_filter_fn()
From: Junio C Hamano @ 2011-11-28 19:18 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Henrik Grubbström, Git Mailing list
In-Reply-To: <20111128104812.GA2386@beez.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
>> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO"
>> Content-Disposition: inline
Please do not do this. It makes it unnecessarily cumbersome to handle
patches without adding much value to the patch.
> --- 8< ---
> Subject: [PATCHv2] convert: track state in LF-to-CRLF filter
>
> There may not be enough space to store CRLF in the output. If we don't
> fill the buffer, then the filter will keep getting called with the same
> short buffer and will loop forever.
>
> Instead, always store the CR and record whether there's a missing LF
> if so we store it in the output buffer the next time the function gets
> called.
>
> Reported-by: Henrik Grubbström <grubba@roxen.com>
> Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
> ---
> convert.c | 50 +++++++++++++++++++++++++++++++++++++-------------
> 1 files changed, 37 insertions(+), 13 deletions(-)
>
> diff --git a/convert.c b/convert.c
> index 86e9c29..1c91409 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -876,24 +876,39 @@ int is_null_stream_filter(struct stream_filter *filter)
> /*
> * LF-to-CRLF filter
> */
> +
> +struct lf_to_crlf_filter {
> + struct stream_filter filter;
> + int want_lf;
> +};
> +
> static int lf_to_crlf_filter_fn(struct stream_filter *filter,
> const char *input, size_t *isize_p,
> char *output, size_t *osize_p)
> {
> - size_t count;
> + size_t count, o = 0;
> + struct lf_to_crlf_filter *lfcrlf = (struct lf_to_crlf_filter *) filter;
> ...
> -};
> +static struct stream_filter *lf_to_crlf_filter(void)
> +{
> + struct lf_to_crlf_filter *lfcrlf = xmalloc(sizeof(*lfcrlf));
>
> + lfcrlf->filter.vtbl = &lf_to_crlf_vtbl;
> + lfcrlf->want_lf = 0;
> + return (struct stream_filter *)lfcrlf;
> +}
Patch looks sane; you may want to rename the variable to lf_crlf at least,
though. The name does not consist of three tokens ("lf", "cr" and "lf")
but of two ("lf" and "crlf"), and your naming loses it.
^ permalink raw reply
* Re: Copy branch into master
From: Andrew Eikum @ 2011-11-28 19:26 UTC (permalink / raw)
To: Ron Eggler; +Cc: git
In-Reply-To: <3655DADD9B52450B81B0CD34F1B0FAB6@bny.us.bosch.com>
On Mon, Nov 28, 2011 at 11:08:33AM -0800, Ron Eggler wrote:
> I guess I'd go for renaming DVT to master.
>
> However, I also played around with merge a little, started a merge (in
> Windows GUI) and aborted it but the icon of my directory keeps showing the
> ywellow exclemation mark, signing that a merge is going on right now but
> going into the directory, all the files are with a geen check mark. What's
> going on here? How do I resolve this - I don't wanna mess things up so I
> might rather resolve this before moving DVT to master.
>
Sorry, I have no idea how to use any of the GUI tools. Perhaps your
GUI tool has a mailing list where you can ask about merge conflict
resolution?
Andrew
^ permalink raw reply
* RE: Copy branch into master
From: Ron Eggler @ 2011-11-28 19:30 UTC (permalink / raw)
To: 'Andrew Eikum'; +Cc: git
In-Reply-To: <20111128192659.GD29503@foghorn.codeweavers.com>
> Sorry, I have no idea how to use any of the GUI tools. Perhaps your
> GUI tool has a mailing list where you can ask about merge conflict
> resolution?
No problem, I actually got it all figured out now, and got my branch
smoothly merged back into master.
Thanks for your help!
Ron
^ permalink raw reply
* Re: git branch -M" regression in 1.7.7?
From: Junio C Hamano @ 2011-11-28 19:38 UTC (permalink / raw)
To: Jonathan Nieder
Cc: ☂Josh Chia (谢任中), git,
Soeren Sonnenburg, Conrad Irwin
In-Reply-To: <20111126023002.GA17652@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> git branch -M master
>
> This seems like a valuable exception to allow, because then "git
> branch -M foo" would _always_ be allowed --- either 'foo' is not the
> current branch, and it does the obvious thing, or 'foo' is the current
> branch, and nothing happens.
>
> Buildbot uses this idiom and was broken in 1.7.7 (it would emit the
> message "Cannot force update the current branch").
Although I am not sure the practice deserves to be called "idiom", I agree
that there is no reason to forbid renaming the current branch to the tip
commit of itself.
Will queue.
^ 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