Re: [PATCH 2/2] mingw: fix getcwd when the parent directory cannot be queried
On Tuesday, October 23, 2018 6:16:43 AM MST Stephen Smith wrote: > On Tuesday, October 23, 2018 3:52:49 AM MST you wrote: > > From: Anton Serbulov > > > > `GetLongPathName()` function may fail when it is unable to query > > the parent directory of a path component to determine the long name > > for that component. It happens, because of it uses `FindFirstFile()` > > s/of it/it/ > > > function for each next short part of path. The `FindFirstFile()` > > requires `List Directory` and `Synchronize` desired access for a calling > > process. BTW - It was "Stephen" that sent the email. :-)
Re: How to handle patch series conflicts
On Monday, October 8, 2018 10:51:09 PM MST Junio C Hamano wrote: > The scripts themselves having the same name that is no more specific > tha just "commit" does not bother _me_ personally too much. If I > were doing it, unless you are an obsessive type that wants to see > spanking cleanness everywhere, I'd limit the changes to the minimum. > No I'm not an obsessive type. sps
Re: inside the git folder
Chris -
You may want to look at "git bundle" to transfer the repository contents.
Then the recipient could fetch from the bundle to get the source git history.
Just a thought.
sps
On Thursday, October 4, 2018 4:03:27 AM MST Johannes Schindelin wrote:
> Hi Chris,
>
> as mentioned by Stefan (who is a respected, active core Git contributor,
> if you need any more arguments to listen to him), it is inappropriate to
> copy the contents of the .git/ directory wholesale to another user's
> machine.
>
> For one, it would horribly break in case the user overrode `user.email` in
> `.git/config`. That's one setting that should not be copied *anywhere*.
> And that's just one, there are *plenty* more examples. Just think of
> absolute paths referring to files that probably do not even exist on
> another machine! Like, worktrees, etc.
>
> Of course, you could start a list of exceptions (files, config keys, etc)
> that should not be copied. But that's very fragile a solution.
>
> So no, copying the .git/ directory is always the wrong thing to do, as
> Stefan pointed out.
>
> I could imagine that a much better idea is to identify a *positive* list
> of things you want to copy over. The output of `git rev-parse
> --symbolic-full-name HEAD`? Sure. Maybe even the output of `git rev-parse
> --symbolic-full-name HEAD@{u}`? And then the URL of the corresponding
> remote? Sure. `.git/objects/alternates/`? Absolutely not.
>
> It is tedious, alright, but you simply cannot copy the contents of .git/
> to another machine and expect that to work.
>
> Ciao,
> Johannes
>
> On Thu, 4 Oct 2018, Chris Jeschke wrote:
> > Hi Stefan,
> >
> > thanks for your answer.
> >
> > The Goal after sending the files is to have a copy on the remote site.
> > This includes that the working directory is the same (what we already
> > guarantee with our tool) and that git is at the same 'state' (that
> > means that we have the same history and that we checkout at the same
> > branch/commit).
> > My idea:
> > Send the working directory with our tool
> > Initialize a Git directory on the remote side
> > Send the 'objects','refs', 'HEAD' and the 'gitignore' with our tool
> >
> > Is there anything else I should take care of?
> >
> > Am Mi., 3. Okt. 2018 um 20:51 Uhr schrieb Stefan Beller
:
> > > On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke
> > >
> > > wrote:
> > > > Hey git-team,
> > > > I am working on a plug-in for a distributed pair programming tool. To
> > > > skip the details: I was thinking about sending parts of the git folder
> > > > as a zip folder with our own Bytestream instead of using the git API.
> > > > Is there a common sense about what should and what shouldn't be done
> > > > when working with the files inside the git folder?
> > >
> > > This contradicts the security model of git.
> > >
> > > Locally I can do things like:
> > > git config alias.co "rm -rf ~"
> > > echo "rm -rf ~" >.git/hooks/{...}
> > >
> > > and I would experience bad things, but that is ok,
> > > as I configured it locally (supposedly I know what
> > > I am doing); but if I have the ability to send these
> > > tricks to my beloved coworkers, hilarity might ensue.
> > >
> > > What stuff do you need to send around?
> > >
> > > objects? Fine, as the receive could check they are
> > > good using fsck.
> > >
> > > refs/ ? Sure. It may be confusing to users,
> > > but I am sure you'll figure UX out.
> > >
> > > local config, hooks ? I would not.
> > >
> > > Not sure what else you'd think of sending around.
> > >
> > > Cheers,
> > > Stefan
Re: [PATCH v3 4/4] wt-status.c: Set the committable flag in the collect phase.
On Friday, September 7, 2018 3:31:55 PM MST Junio C Hamano wrote: > For example, I noticed that both of the old > callsites of wt_status_get_state() have free() of a few fiedls in > the structure, and I kept the code as close to the original, but I > suspect they should not be freed there in the functions in the > "print" phase, but rather the caller of the "collect" and "print" > should be made responsible for deciding when to dispose the entire > wt_status (and wt_status_state as part of it). This illustration > patch does not address that kind of details (yet). I followed the call tree back to original callers run_status() and cmd_status() in commit.c This leads to a philosophical question. We want to move the state information out of the print functions because it doesn't seem correct. For the case in question this includes the calls to free() . By doing this we seem go have traded one location that shouldn't be touching the state variables for another. I can see three solutions and could support any of the three: 1) Move the free calls to run_status() and cmd_status(). 2) Move the calls calls to wt_status_print since that is the last function from wt_status.c that is called befor the structure goes out of scope in run_status() and cmd_status(). 3) Add a new wt_collect*() function to free the variables. This would have an advantage that the free calls could be grouped in on place and not done in to functions. A second advantage is that the free calls would be located where the pointers are initialized. Personally I like solutions 1 and 3 over 2. What do others think? sps
Re: How to handle patch series conflicts
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote: > I think that one that is not even in 'pu' hasn't been looked at for > a long time; it is probably a good idea to discard and replace, if > you have something working. I submitted a working patch set yesterday. [1] https://public-inbox.org/git/20180906005329.11277-1-isch...@cox.net/T/ #m3ed5a15721318f71064dbe7225be9242c3960e1c sps
Re: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.
On Tuesday, February 16, 2016 8:33:54 PM MST Junio C Hamano wrote: > In fact, "commit --dry-run" is already broken without this "a merge > ends up in a no-op" corner case. The management of s->commitable > flag and dry_run_commit() that uses it are unfortunately more broken > than I originally thought. > > This function is only called from wt_status_print(), which in turn > is only called from run_status() in commit.c when the status format > is unspecified or set to STATUS_FORMAT_LONG. > > So if you do this: > > $ git reset --hard HEAD > $ >a-new-file && git add a-new-file > $ git commit --dry-run --short; echo $? > > you'd get "No, there is nothing interesting to commit", which is > clearly bogus. I was about to start working on working on this and ran the test you suggested back in 2016. I don't get the error message from that time period. I believe that this was fixed.
Is the a way to get a log with files that were changed
Is there a way to get a log of first parent commits and with each commit a entry a list of the files that were changed? SPS Sent from my iPhone-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] How to keep a project's canonical history correct.
On May 8, 2014, at 11:08 PM, Stephen P. Smith isch...@cox.net wrote: During the mail thread about Pull is mostly evil a user asked how the first parent could become reversed. This howto explains how the first parent can get reversed when viewed by the project and then explains a method to keep the history correct. Signed-off-by: Stephen P. Smith isch...@cox.net --- The reason I resubmitted as a brand new patch was because I was using the message ID from the original topic as requested. In my repository I did a git merge --squash then the format patch. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git subtree oddity
I built v1.8.2 last evening and found that the subtree command isn't supported. What version of git are you using? And where did you get it? SPS Sent from my iPhone On Mar 27, 2013, at 8:12 PM, Thomas Taranowski t...@baringforge.com wrote: I'd like to have the following configuration: /myproject.git |__/upstream_dependency -- Points to a remote library git repo |__/project_source -- local project source I issue the following commands to pull in the upstream dependency as a subtree of the myproject.git repo: git remote add upstream git://gnuradio.org/gnuradio git fetch upstream git checkout master git subtree add -P upstream upstream/master Now, my expectation is that I would have the following: /myproject.git |__/upstream_dependency -- Points to a remote library git repo | all the upstream files are present here, as expected |__/project_source this is still intact, as expected |__ all the upstream files are present here. wtf? My question is, why does subtree add pull in all the subtree files into the root of the repo, and not just into the specified subtree prefix? # # Here's an excerpt of what I see: # $:~/scratch/myproject.git$ ls AUTHORS gr-comedi gr-utils cmake gr-digital gr-video-sdl CMakeLists.txt gr-fcd gr-vocoder config.h.in gr-fft gr-wavelet COPYING gr-filter gr-wxgui docsgr-howto-write-a-block README dtools gr-noaa README.building-boost gnuradio-core gr-pagerREADME.hacking gr-analog gr-qtguiREADME-win32-mingw-short.txt gr-atsc gr-shd upstream the subtree directory gr-audiogr-trellis volk gr-blocks gruel grc gr-uh # # Also, those same files are in the upstream subtree directory as well (as expected) # $:~/scratch/myproject.git$ ls upstream AUTHORS grc gruel cmake gr-comedi gr-uhd CMakeLists.txt gr-digital gr-utils config.h.in gr-fcd gr-video-sdl COPYING gr-fft gr-vocoder docsgr-filter gr-wavelet dtools gr-howto-write-a-block gr-wxgui gnuradio-core gr-noaa README gr-analog gr-pagerREADME.building-boost gr-atsc gr-qtguiREADME.hacking gr-audiogr-shd README-win32-mingw-short.txt gr-blocks gr-trellis volk -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
Ideally we'd prefer to simply create our remote repository on a drive of one of our local network servers. Is this possible? Yes, this is possible, but it's not advised to keep such a reference repository on an exported networked drive for a number of reasons (both performance and bug-free operation). I agree that performance is not ideal (although if you are on a fast LAN, it probably would not matter much), but I do not recall any specific bugs in that area. Can you elaborate? This one [1] for instance. I also recall seing people having other mystical problems with setups like this so I somehow developed an idea than having a repository on a networked drive is asking for troubles. Of course, if there are happy users of such setups, I would be glad to hear as my precautions might well be unfounded for the recent versions of Git. 1. http://code.google.com/p/msysgit/issues/detail?id=130 A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
