* Re: [PATCH 05/13] Help.c: add list_common_guides_help() function
From: Philip Oakley @ 2013-02-25 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GitList
In-Reply-To: <7vk3px3qzp.fsf@alter.siamese.dyndns.org>
On 25/02/13 05:24, Junio C Hamano wrote:
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> From: "Junio C Hamano" <gitster@pobox.com>
>> Sent: Sunday, February 24, 2013 9:01 AM
>>> Philip Oakley <philipoakley@iee.org> writes:
>>>
>>>> diff --git a/common-guides.h b/common-guides.h
>>>> new file mode 100644
>>>> index 0000000..a8ad8d1
>>>> --- /dev/null
>>>> +++ b/common-guides.h
>>>> @@ -0,0 +1,12 @@
>>>> +/* Automatically generated by ./generate-guidelist.sh */
>>>> +/* re-use struct cmdname_help in common-commands.h */
>>>
>>> Huh?
>> The first comment line fortells of patch 6 which can generate this .h
>> file.
>
> The Huh? was about that one, not about reuse. I do not want to see
> a build artifact kept in the history without a good reason.
>
I'd copied it from generate-cmdlist.sh which is a common-cmd.h
dependency and was introduced by
commit a87cd02ce02e97083eb76eb8b9bfeb2e46800fd7
Author: Fredrik Kuivinen <freku045@student.liu.se>
Date: Thu Mar 9 17:24:19 2006 +0100
Nicer output from 'git'
[jc: with suggestions by Jan-Benedict Glaw]
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The reason in this (my) case, as then, is that it states how the file is
generated so that it can be regenerated later. If the patches are
successful then I'd want the generate-guidelist and generate-cmdlist to
be joined together as an integral part of generating the help system data.
Mind you each review point turns over another stone that needs to be
considered, such as the Makefile link of common-commands.h and similarly
for the Documentation/Makefile - I'm thinking of the issues around
'gitk' and its ilk which isn't a common command (because it has no
hyphen) yet is in the command list, so can be confused with the support
documentation, however I don't mark it as a common guide, so that's OK.
('git help k' does offer the gitk man page ;-)
I'll tidy up the series over the next few days to include the points so far
Philip
^ permalink raw reply
* Re: [PATCH v2 0/2] improve-wincred-compatibility
From: Junio C Hamano @ 2013-02-25 23:51 UTC (permalink / raw)
To: Karsten Blees
Cc: kusmabite, git, msysgit, Jeff King, patthoyts,
Johannes.Schindelin
In-Reply-To: <512BF61B.4020708@dcon.de>
Karsten Blees <karsten.blees@gmail.com> writes:
> Am 25.02.2013 07:43, schrieb Junio C Hamano:
>> Erik Faye-Lund <kusmabite@gmail.com> writes:
> ...
>> I'm in the "marking leftover bits" mode today, and noticed that
>> nothing happened for this topic in my tree. Did msysgit folks expect
>> me to pick this up directly, or did you guys want to feed this series
>> to me (with possibly other changes you worked on outside this list)?
>
> The second patch changes the credential format in a
> backward-incompatible way, so I think this should be in git.git,
> too (better than having two incompatible versions around).
I am a bit confused by that comment, as it was my understanding that
the "credential format" only refers to what is stored in the Windows
specific credential storage and relevant only to users of msysgit
(and I expected folks who are using Git natively on Windows to be
using msysgit, not git.git), but in any case, of course we would
want a single version and format. My question was if msysgit folks
want me to take your patch (which I cannot test myself) and then
merge my tree to the msysgit tree as part of their regular updates
to catch up with 1.8.2 (and future releases), or they want to test
your patches in their tree first, and then either throw me a pull
request or send me a patch series with Acked-by:.
I can obviously go either way, but if they expect the former (i.e. I
first apply and they pull) while I expect the latter (i.e. they
first apply and I pull), then nothing will happen, and if we go the
other way around, we would end up getting two copies of the same
series. The question was primarily to avoid these possibilities.
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH 05/13] Help.c: add list_common_guides_help() function
From: Junio C Hamano @ 2013-02-25 23:55 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <512BF72F.9030404@iee.org>
Philip Oakley <philipoakley@iee.org> writes:
>>> The first comment line fortells of patch 6 which can generate this .h
>>> file.
>>
>> The Huh? was about that one, not about reuse. I do not want to see
>> a build artifact kept in the history without a good reason.
>>
> I'd copied it from generate-cmdlist.sh which is a common-cmd.h
> dependency and was introduced by
>
> commit a87cd02ce02e97083eb76eb8b9bfeb2e46800fd7
> Author: Fredrik Kuivinen <freku045@student.liu.se>
> Date: Thu Mar 9 17:24:19 2006 +0100
>
> Nicer output from 'git'
>
> [jc: with suggestions by Jan-Benedict Glaw]
>
> Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Looking at the change again, I do not see us adding a build artifact
(in the case of that patch, common-cmd.h) to our history. Only the
recipe to generate that file exists there, which is the right thing
to do.
Why do we want common-guides.h which is clearly marked as "A
generated file" at its top in our history? That was what made me
say "Huh?".
^ permalink raw reply
* Re: [PATCH 12/13] Documentation/Makefile: update git guide links
From: Junio C Hamano @ 2013-02-26 0:04 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <512BF71E.3080304@iee.org>
Philip Oakley <philipoakley@iee.org> writes:
> On 25/02/13 05:29, Junio C Hamano wrote:
> ...
>> In other words, can't you change the side that launches the document
>> viewer so that we do not have to rename anything in the first place?
>
> The current help code will only show either 'git-<cmd>' man pages, or
> git<guide>' pages so the current everyday and user-manual pages aren't
> served by the existing help code.
That is exactly what I meant by "the side that launches the document
viewer". We obviously would not want to type
$ git help gituser-manual
$ git help giteveryday
I was wondering if you can keep document names as-is, register these
names without "git" prefix (i.e. "user-manual.html") to the list of
guide documents you are generating and compiling into the binary,
and let the user ask:
$ git help everyday
which you would turn into "browser %s/%s.html" % (GIT_HTML_PATH, 'everyday'),
after checking "everyday" is one of the guides that are available to us.
If some guides are already named with git prefix, you can keep them
in the compiled-in list with that name. We do not have to worry
about redirects and people's bookmarks if we can avoid renaming
existing pages, so "because grabbing everything with git* glob was
easier to write the generate-guidelist script" is a false economy.
That is the single place we can afford to spend extra effort to make
the end result easier to use by the users, no?
Or am I misreading the series completely?
^ permalink raw reply
* Re: post-receive-email hook with custom_showrev
From: Adam Mercer @ 2013-02-26 1:39 UTC (permalink / raw)
To: git
In-Reply-To: <CA+mfgz1jrSbbZc7+asxfZivemYSvbB3+UxYx4sm3BwLmR0ELEA@mail.gmail.com>
On Fri, Feb 22, 2013 at 2:57 PM, Adam Mercer <ramercer@gmail.com> wrote:
> So it seems as if showrev is being ignored? Can anyone see what I'm doing wrong?
Anyone? From looking at the documentation I can't see anything wrong
but as it's not displaying anything something is clearly wrong.
Cheers
Adam
^ permalink raw reply
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
From: Mark Levedahl @ 2013-02-26 4:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jonathan Nieder, Eric Blake, Alex Riesen, Jason Pyeron,
Torsten Bögershausen, Stephen & Linda Smith,
Ramsay Jones
In-Reply-To: <7vliac3nbg.fsf@alter.siamese.dyndns.org>
On 02/25/2013 01:44 AM, Junio C Hamano wrote:
> I was in "find leftover bits" mode today and found this thread
> hanging. Has anything come out of this thread, or there is nothing to
> improve in this area?
The patch passed my simple tests (build, run a few commands), but I
didn't get around to a full test. And of course, I am testing on current
Cygwin where git compiles and runs correctly anyway.
Mark
^ permalink raw reply
* Re: [RFC/WIP PATCH 1/3] teach config parsing to read from strbuf
From: Jeff King @ 2013-02-26 4:55 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, git, Jens Lehmann
In-Reply-To: <6c69068b4e6a72a2cca5dc6eaffa9982032a7f2a.1361751905.git.hvoigt@hvoigt.net>
On Mon, Feb 25, 2013 at 02:04:18AM +0100, Heiko Voigt wrote:
> This can be used to read configuration values directly from gits
> database.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
FWIW, I implemented something quite similar as a 2-patch series here:
http://article.gmane.org/gmane.comp.version-control.git/189142
http://article.gmane.org/gmane.comp.version-control.git/189143
but they were never merged as we ended up throwing out the feature built
on top (including config from blobs). I didn't look too closely at your
implementation, but it looks like you touched the same spots in the same
way. Which is probably a good thing, and may give another data point for
Junio's "what would it look like to read another source" comment.
-Peff
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Jaseem Abid @ 2013-02-26 4:59 UTC (permalink / raw)
To: Thomas Rast
Cc: git@vger.kernel.org, Jeff King, Shawn Pearce, Jakub Narebski,
Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, David Michael Barr,
Ramkumar Ramachandra, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <87ehgd1qq2.fsf@pctrast.inf.ethz.ch>
On Mon, Feb 18, 2013 at 10:53 PM, Thomas Rast <trast@inf.ethz.ch> wrote:
> * We should prepare an "ideas page". Last year, Peff made one on
> https://github.com/peff/git/wiki/SoC-2012-Ideas
[Resending the mail, because the last one failed because of inline html content]
One of the proposed ideas last year - 'Use JavaScript library /
framework in gitweb'
I wanted to work on this project last year, but Git community didn't
get a slot for the project from Google. I still worked on it and
almost finished it. Sadly I never got time to polish it to merge to
master. you can see some of my commits on it here.
https://github.com/jaseemabid/git/commits/gitweb
Detailed notes on what actually did.
https://gist.github.com/jaseemabid/3218461
Gitweb is 1 huge perl script and even though it *works*, it is a poor
work in 2013. The code is pretty old and is a hard thing to jump into.
Quite a few here helped me to get started and it was a pretty good
experience. Jakub was the mentor. Ram and John 'warthog' Hawley
occasionally helped with git and general feedback back then. Andrew
Sayers <andrew-git@pileofstuff.org> helped a lot, but he just
disappeared one day. I remember John mentioning about splitting the
file into smaller ones, rewriting some sections, adding more
documentation etc. I'm not sure if any work was done on this. I
couldn't follow the project for sometime.
I will try to make some time and finish it off in the next week or so.
I am having a bad schedule now between school and job, but will try my
level best.
--
Regards,
Jaseem Abid
github.com/jaseemabid
^ permalink raw reply
* Re: [PATCH ] t4210-log-i18n: spell encoding name "UTF-8" correctly
From: Johannes Sixt @ 2013-02-26 6:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Thomas Haller, Git List
In-Reply-To: <20130225203100.GA15932@sigill.intra.peff.net>
Am 2/25/2013 21:31, schrieb Jeff King:
> Subject: [PATCH] utf8: accept alternate spellings of UTF-8
> ...
> JSixt, can you double-check that this passes t4210 for you?
Yes, t4210 and all other *i18n* and *log* tests pass with this patch.
Thanks,
-- Hannes
>
> utf8.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/utf8.c b/utf8.c
> index 1087870..8f6e84b 100644
> --- a/utf8.c
> +++ b/utf8.c
> @@ -507,9 +507,25 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
>
> if (!in_encoding)
> return NULL;
> +
> conv = iconv_open(out_encoding, in_encoding);
> - if (conv == (iconv_t) -1)
> - return NULL;
> + if (conv == (iconv_t) -1) {
> + /*
> + * Some platforms do not have the variously spelled variants of
> + * UTF-8, so let's fall back to trying the most official
> + * spelling. We do so only as a fallback in case the platform
> + * does understand the user's spelling, but not our official
> + * one.
> + */
> + if (is_encoding_utf8(in_encoding))
> + in_encoding = "UTF-8";
> + if (is_encoding_utf8(out_encoding))
> + out_encoding = "UTF-8";
> + conv = iconv_open(out_encoding, in_encoding);
> + if (conv == (iconv_t) -1)
> + return NULL;
> + }
> +
> out = reencode_string_iconv(in, strlen(in), conv);
> iconv_close(conv);
> return out;
^ permalink raw reply
* [PATCH] RelNotes/1.8.1.5: mention correct 'Fixes since'
From: Stefan Naewe @ 2013-02-26 7:12 UTC (permalink / raw)
To: gitster, git; +Cc: Stefan Naewe
RelNotes/1.8.1.5.txt mentions 'Fixes since v1.8.1.5'
which should obviously be empty. This fixes it.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
Documentation/RelNotes/1.8.1.5.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.5.txt b/Documentation/RelNotes/1.8.1.5.txt
index 92da6b2..0fb94a9 100644
--- a/Documentation/RelNotes/1.8.1.5.txt
+++ b/Documentation/RelNotes/1.8.1.5.txt
@@ -1,7 +1,7 @@
Git 1.8.1.5 Release Notes
=========================
-Fixes since v1.8.1.5
+Fixes since v1.8.1.4
--------------------
* "git apply --summary" has been taught to make sure the similarity
--
1.8.1.msysgit.1
^ permalink raw reply related
* state of the art with moving submodules
From: Chris Packham @ 2013-02-26 8:09 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git@vger.kernel.org
In-Reply-To: <bcaec55555fe91182f04d698b37f@google.com>
Hi Jens,
(sorry for the dup. gmail insists on sending html)
I know I saw a few threads regarding support for moving submodules but I
lost track of the discussion.
At $dayjob we were discussing a potential re-org of our super-projects
to introduce a bit of hierarchy to the submodules (at the moment it's
fairly flat). One downside of this is the potential loss of locally
committed work. There is also a cost in terms of additional fetching but
we think that will be OK (fetches from local servers with smallish repos).
I was just wondering where things were at with git detecting submodule
moving/renaming? Will our developers be able to keep any local commits
when they happen to pull in the super-project commit that moves a commit.
I think some people with older clones will suffer without the newer
.git/modules layout but those can be manually fixed prior to the re-org.
FYI our current stock workstation install uses git version 1.7.9.5 but
I'm recommending we update to 1.8.x before this re-org to pick up some
of the recent submodule improvements.
Thanks
Chris
^ permalink raw reply
* git subtree workflow
From: Ben McCann @ 2013-02-26 9:04 UTC (permalink / raw)
To: git
I'm fairly new to git and am trying to determine if git subtree would
be helpful for managing our company's codebase, which has several
repos some of which depend on each other. All the examples I've seen
make sense to me as a one-time operation to merge separate repos into
one monolithic one or to split one monolithic repo into separate
repos. I'm having a harder time understanding how this fits into a
larger picture and what the workflow for working with subtree would
be.
If I have a bunch of repos on GitHub and some depend on each other,
how would I set them up to work with subtree? Would GitHub continue to
host them as is, host a merged monolithic repo, or host both a
monolithic repo and the splitted out repos? The exact answer probably
varies, but I imagine there's basic workflow that would satisfy 80% of
users. If I have GitHub host both monolithic and splitted out repos,
it seems unclear as to how I keep those repos in sync and make sure
all the developers in our company push their changes to both repos.
Thanks,
Ben
^ permalink raw reply
* Re: Git 1.8.2 l10n round 3
From: Jiang Xin @ 2013-02-26 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7v4nh0z3nr.fsf@alter.siamese.dyndns.org>
Hi Junio,
Additional pull request for git 1.8.2 l10n round 3, which has
Germany translation updates.
The following changes since commit 4dac0679feaebbf6545daec14480cf6b94cb74ed:
Git 1.8.2-rc1 (2013-02-25 09:03:26 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 5e93cd307bdb98809bb0aa3bfb2c0306131f3654:
l10n: de.po: correct translation of "bisect" messages (2013-02-26
07:38:34 +0100)
----------------------------------------------------------------
Ralf Thielow (3):
l10n: de.po: translate 35 new messages
l10n: de.po: translate 5 new messages
l10n: de.po: correct translation of "bisect" messages
po/de.po | 1457 +++++++++++++++++++++++++++++++++++---------------------------
1 file changed, 821 insertions(+), 636 deletions(-)
--
Jiang Xin
^ permalink raw reply
* [PATCH/RFC] Record original ref in detached HEAD
From: Nguyễn Thái Ngọc Duy @ 2013-02-26 14:28 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Many times I checkout a remote branch, or a tag and after a while I
forget remember what ref I checked it out from. Saving the original
ref would help (or is it already saved somewhere?).
This exploits the fact that FETCH_HEAD stores extra info after the
SHA-1 and at least C Git is prepared to ignore the rest after 40-hex
is successfully parsed for all refs, including HEAD. We could use this
to store the original ref in detached case, as demonstrated in this
patch. "git status" and "git branch" could be modified to show this
information later on. I think it should work even with Git 0.99.8
(I have not really verified though).
So far C Git runs well for me. Other implementations like libgit2 or
JGit may be stricter and reject modified HEAD. I have to check. But I
think HEAD is a local matter and this is not a big deal.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/checkout.c | 6 ++++--
refs.c | 37 ++++++++++++++++++++++++++++++-------
refs.h | 5 +++++
3 files changed, 39 insertions(+), 9 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index a9c1b5a..82fccbe 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -594,8 +594,10 @@ static void update_refs_for_switch(const struct checkout_opts *opts,
if (!strcmp(new->name, "HEAD") && !new->path && !opts->force_detach) {
/* Nothing to do. */
} else if (opts->force_detach || !new->path) { /* No longer on any branch. */
- update_ref(msg.buf, "HEAD", new->commit->object.sha1, NULL,
- REF_NODEREF, DIE_ON_ERR);
+ update_ref_with_note(msg.buf, "HEAD",
+ new->commit->object.sha1,
+ new->path, NULL,
+ REF_NODEREF, DIE_ON_ERR);
if (!opts->quiet) {
if (old->path && advice_detached_head)
detach_advice(new->name);
diff --git a/refs.c b/refs.c
index 175b9fc..b67c3b1 100644
--- a/refs.c
+++ b/refs.c
@@ -2045,10 +2045,13 @@ static int is_branch(const char *refname)
return !strcmp(refname, "HEAD") || !prefixcmp(refname, "refs/heads/");
}
-int write_ref_sha1(struct ref_lock *lock,
- const unsigned char *sha1, const char *logmsg)
+static int write_ref_sha1_with_note(struct ref_lock *lock,
+ const unsigned char *sha1,
+ const char *note,
+ const char *logmsg)
{
static char term = '\n';
+ static char note_separator = '\t';
struct object *o;
if (!lock)
@@ -2071,7 +2074,10 @@ int write_ref_sha1(struct ref_lock *lock,
return -1;
}
if (write_in_full(lock->lock_fd, sha1_to_hex(sha1), 40) != 40 ||
- write_in_full(lock->lock_fd, &term, 1) != 1
+ (note &&
+ (write_in_full(lock->lock_fd, ¬e_separator, 1) != 1 ||
+ write_in_full(lock->lock_fd, note, strlen(note)) != strlen(note))) ||
+ write_in_full(lock->lock_fd, &term, 1) != 1
|| close_ref(lock) < 0) {
error("Couldn't write %s", lock->lk->filename);
unlock_ref(lock);
@@ -2114,6 +2120,13 @@ int write_ref_sha1(struct ref_lock *lock,
return 0;
}
+int write_ref_sha1(struct ref_lock *lock,
+ const unsigned char *sha1,
+ const char *logmsg)
+{
+ return write_ref_sha1_with_note(lock, sha1, NULL, logmsg);
+}
+
int create_symref(const char *ref_target, const char *refs_heads_master,
const char *logmsg)
{
@@ -2411,9 +2424,11 @@ int for_each_reflog(each_ref_fn fn, void *cb_data)
return retval;
}
-int update_ref(const char *action, const char *refname,
- const unsigned char *sha1, const unsigned char *oldval,
- int flags, enum action_on_err onerr)
+int update_ref_with_note(const char *action, const char *refname,
+ const unsigned char *sha1,
+ const char *note,
+ const unsigned char *oldval,
+ int flags, enum action_on_err onerr)
{
static struct ref_lock *lock;
lock = lock_any_ref_for_update(refname, oldval, flags);
@@ -2426,7 +2441,7 @@ int update_ref(const char *action, const char *refname,
}
return 1;
}
- if (write_ref_sha1(lock, sha1, action) < 0) {
+ if (write_ref_sha1_with_note(lock, sha1, note, action) < 0) {
const char *str = "Cannot update the ref '%s'.";
switch (onerr) {
case MSG_ON_ERR: error(str, refname); break;
@@ -2438,6 +2453,14 @@ int update_ref(const char *action, const char *refname,
return 0;
}
+int update_ref(const char *action, const char *refname,
+ const unsigned char *sha1, const unsigned char *oldval,
+ int flags, enum action_on_err onerr)
+{
+ return update_ref_with_note(action, refname, sha1, NULL,
+ oldval, flags, onerr);
+}
+
struct ref *find_ref_by_name(const struct ref *list, const char *name)
{
for ( ; list; list = list->next)
diff --git a/refs.h b/refs.h
index 1b2e2d3..9fbba2e 100644
--- a/refs.h
+++ b/refs.h
@@ -146,6 +146,11 @@ enum action_on_err { MSG_ON_ERR, DIE_ON_ERR, QUIET_ON_ERR };
int update_ref(const char *action, const char *refname,
const unsigned char *sha1, const unsigned char *oldval,
int flags, enum action_on_err onerr);
+int update_ref_with_note(const char *action, const char *refname,
+ const unsigned char *sha1,
+ const char *note,
+ const unsigned char *oldval,
+ int flags, enum action_on_err onerr);
extern int parse_hide_refs_config(const char *var, const char *value, const char *);
extern int ref_is_hidden(const char *);
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* Re: [PATCH/RFC] Record original ref in detached HEAD
From: Matthieu Moy @ 2013-02-26 14:37 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1361888897-1821-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Many times I checkout a remote branch, or a tag and after a while I
> forget remember what ref I checked it out from. Saving the original
> ref would help (or is it already saved somewhere?).
It is :-). Try e.g.
git checkout --detach
git checkout -
(analogous to "cd -": return back to where you were before)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH/RFC] Record original ref in detached HEAD
From: Duy Nguyen @ 2013-02-26 14:57 UTC (permalink / raw)
To: Matthieu Moy, Tomas Carnecky; +Cc: git
In-Reply-To: <vpqsj4jqgy4.fsf@grenoble-inp.fr>
On Tue, Feb 26, 2013 at 9:37 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> Many times I checkout a remote branch, or a tag and after a while I
>> forget remember what ref I checked it out from. Saving the original
>> ref would help (or is it already saved somewhere?).
>
> It is :-). Try e.g.
>
> git checkout --detach
> git checkout -
>
> (analogous to "cd -": return back to where you were before)
Yeah. I always manage to forget reflog when I need it. Time to show
the information in "git branch", oh wait I still have a wip about
git-branch on pu..
--
Duy
^ permalink raw reply
* Re: Possible regression in ref advertisement
From: Carlos Martín Nieto @ 2013-02-26 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff
In-Reply-To: <7vfw0kt7qc.fsf@alter.siamese.dyndns.org>
On Mon, 2013-02-25 at 13:16 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> >> As packed-refs file is expected to be a text file, it is not
> >> surprising to get an undefined result if the it ends with an
> >> incomplete line.
> >
> > I guess that depends on what you mean by incomplete.
>
> I used that word in the POSIX sense, i.e.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_67
Huh, I must revise my POSIX. Sure, in that sense it's incomplete.
>
> Unless the user edited the file, an incomplete line may indicate
> that the file has been truncated when (or after) it was written, and
> we have to suspect not just that the last "line" may have been
> truncated (in this case, not having the full 40-hex object name),
> but other records that should have been after that line were lost.
>
> We may want to detect such corruption at runtime, at least at
> strategic places; making it a hard runtime error will make it
> difficult to use Git itself to recover from such an corruption
> (e.g. you may have a healty mirror from which you can recover refs
> with "fetch --mirror").
Since the libgit2 parser seems to work with it, it's perfectly possible
I did mess about with the file and then promptly forgot. An error would
definitely not help here, but I do think a warning should be issued if
the file isn't quite as it should be. It seems the parser can already
detect this, so it could be as easy as adding a fprintf(stderr, "...").
>
> We should at least refrain from running repack/gc to make things
> worse, for example.
>
Sounds sensible, yep.
cmn
^ permalink raw reply
* gc does not clean up after itself when not enough disk space
From: jones.noamle @ 2013-02-26 15:38 UTC (permalink / raw)
To: git
In-Reply-To: <512CD689.4050705@gmail.com>
When git gc fails on no more disk space, it leaves tmp_pack files lying
around that consume whatever space was available (and fill up the disk
to 100%). Shouldn't git be deleting these files?
Running git 1.7.9 on cygwin:
# git --version
git version 1.7.9
# uname -a
CYGWIN_NT-6.1-WOW64 ---- 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin
Example failure output:
# git gc
Counting objects: 44626, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7756/7756), done.
fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No
space left on device
error: failed to run repack
Thanks!
Noam
^ permalink raw reply
* Re: Possible regression in ref advertisement
From: Junio C Hamano @ 2013-02-26 15:46 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git, peff
In-Reply-To: <1361891069.9005.11.camel@flaca.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> Since the libgit2 parser seems to work with it, it's perfectly possible
> I did mess about with the file and then promptly forgot. An error would
> definitely not help here, but I do think a warning should be issued if
> the file isn't quite as it should be. It seems the parser can already
> detect this, so it could be as easy as adding a fprintf(stderr, "...").
Yeah, another thing that may be worth checking is if this was
written/corrupted by hand, in which case there is no need to worry
about it further, or by something else, e.g. reimplementations such
as jgit and libgit2, or a third-party tool that wants to be
compatible with Git, in which case we do want to see that get fixed.
^ permalink raw reply
* Better handling of erroneous git stash save "somemessage" --keep-index
From: Gunnlaugur Thor Briem @ 2013-02-26 15:59 UTC (permalink / raw)
To: git
Hi,
the command:
git stash save "some message" --keep-index
stashes everything, including the index, and adds the "--keep-index"
to the message. The manual labor of separating index hunks from hunks
to stash is lost. This is in version 1.8.1.3.
This is a user error, of course (per the man page, parameters are not
accepted after the message). But it would be better handled by
erroring out, with a message like "git stash save does not permit
parameters after the stash message".
Cheers,
Gulli
^ permalink raw reply
* Re: gc does not clean up after itself when not enough disk space
From: Junio C Hamano @ 2013-02-26 16:07 UTC (permalink / raw)
To: jones.noamle; +Cc: git
In-Reply-To: <512CD703.4080302@gmail.com>
"jones.noamle" <lenoam@gmail.com> writes:
> # git gc
> Counting objects: 44626, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (7756/7756), done.
> fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No
> space left on device
In general when we encounter an unexpected error, we tend to try
leaving things as they are so that we can help diagnosing the
failure. But when you ran out of disk space I would agree that it
may be sensible to remove a temporary file we didn't manage to write
out in full.
^ permalink raw reply
* Re: Better handling of erroneous git stash save "somemessage" --keep-index
From: Junio C Hamano @ 2013-02-26 16:10 UTC (permalink / raw)
To: Gunnlaugur Thor Briem; +Cc: git
In-Reply-To: <CAPs+M8JvcnTcZiySmpMBuOxek4THRnTx0jkZv7NHaSDNLhcOAQ@mail.gmail.com>
Gunnlaugur Thor Briem <gunnlaugur@gmail.com> writes:
> the command:
>
> git stash save "some message" --keep-index
>
> stashes everything, including the index, and adds the "--keep-index"
> to the message. The manual labor of separating index hunks from hunks
> to stash is lost. This is in version 1.8.1.3.
>
> This is a user error, of course (per the man page, parameters are not
> accepted after the message). But it would be better handled by
> erroring out, with a message like "git stash save does not permit
> parameters after the stash message".
Then the user cannot say
git stash save some message that consists of multiple words
no? You may have a WIP to enhance the behaviour of one option and
you might want to say
git stash save wip: tweak behaviour of --keep-index
to save it away when switching to higher priority task.
^ permalink raw reply
* Re: [PATCH v2 0/2] improve-wincred-compatibility
From: Johannes Schindelin @ 2013-02-26 16:19 UTC (permalink / raw)
To: Karsten Blees
Cc: Junio C Hamano, kusmabite, git, msysgit, Jeff King, patthoyts
In-Reply-To: <512BF61B.4020708@dcon.de>
Hi Karsten,
On Tue, 26 Feb 2013, Karsten Blees wrote:
> @Pat, Dscho: the rebase-merge script should automatically drop patches
> found in upstream, correct?
Yep, that's the idea. Under some circumstances, --cherry will fail to pick
up on it and the commits will still be marked for 'pick', but when it
comes to them, there will be no changes to be committed.
Ciao,
Dscho
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: Better handling of erroneous git stash save "somemessage" --keep-index
From: Matthieu Moy @ 2013-02-26 16:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gunnlaugur Thor Briem, git
In-Reply-To: <7vwqtvm4yr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Gunnlaugur Thor Briem <gunnlaugur@gmail.com> writes:
>
>> the command:
>>
>> git stash save "some message" --keep-index
>>
>> stashes everything, including the index, and adds the "--keep-index"
>> to the message. The manual labor of separating index hunks from hunks
>> to stash is lost. This is in version 1.8.1.3.
Not lost, it's saved as part of the stash. "git stash pop --index" will
restore it.
>> This is a user error, of course (per the man page, parameters are not
>> accepted after the message). But it would be better handled by
>> erroring out, with a message like "git stash save does not permit
>> parameters after the stash message".
>
> Then the user cannot say
>
> git stash save some message that consists of multiple words
>
> no?
I didn't even know that multi-words messages would be allowed this way.
That seems to me to be really weird indeed.
I can't say
git commit -m multi word message
so why would people want to omit quotes for "git stash" is a total
mystery. That said, we can't deny it right now, to preserve backward
compatibility.
My feeling is that "git stash save" should learn a "-m, --message"
option analogous to the one of "git commit", and then the "message on
the command-line" syntax could be deprecated.
(One nice side effect would be that in the very long term, we may want
to allow "git stash save -- <pathspecs>" to do a limited stash)
But maybe it's not worth the effort, I don't know.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
From: Torsten Bögershausen @ 2013-02-26 16:40 UTC (permalink / raw)
To: Mark Levedahl
Cc: Junio C Hamano, git, Jonathan Nieder, Eric Blake, Alex Riesen,
Jason Pyeron, Torsten Bögershausen,
Stephen & Linda Smith, Ramsay Jones
In-Reply-To: <512C3554.8020902@gmail.com>
On 26.02.13 05:08, Mark Levedahl wrote:
> On 02/25/2013 01:44 AM, Junio C Hamano wrote:
>> I was in "find leftover bits" mode today and found this thread hanging. Has anything come out of this thread, or there is nothing to improve in this area?
>
> The patch passed my simple tests (build, run a few commands), but I didn't get around to a full test. And of course, I am testing on current Cygwin where git compiles and runs correctly anyway.
>
> Mark
I run the test suite, and there was 1301 failing (and t0070 ?) which have
to do with POSIX permisions.
They are on my TODO stack.
/Torsten
^ 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